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Executive  Summary 


This  report  describes  the  Accelerated  Improvement  Method  (AIM),  which  implements  CMMI 
practices  rapidly,  reliably,  and  with  high  performance.  AIM  combines  the  Team  Software  Process 
(TSP)  and  tailored  SCAMPI  appraisals  with  elements  of  Six  Sigma  and  other  techniques  to 
achieve  typical  project  productivity  gains  of  30%  while  reducing  delivered  defect  rates  by  80% 
and  conforming  to  CMMI  maturity  level  3  practices,  nominally  within  18  months  for  small-to- 
medium  sized  organizations.  AIM  starts  up  quickly  with  known  costs  and  proceeds  project-by- 
project  until  the  entire  organization  has  been  transformed.  This  document  provides  guidance  to 
AIM  implemented  but  also  provides  background  information  for  executives,  line  managers,  and 
other  affected  parties.  It  is  a  companion  to  the  Guide  for  SCAMPI  Appraisals:  Accelerated 
Improvement  Method  (AIM)  [Miluk2010], 
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Abstract 


This  report  is  a  description  of  and  aid  for  implementing  the  Accelerated  Improvement  Method 
(AIM),  and  is  a  companion  to  the  Guide  for  SCAMPI  Appraisals:  Accelerated  Improvement 
Method  (AIM).  The  intended  audience  is  anyone  responsible  for  implementing  CMMI  using  the 
Team  Software  Process  (TSP),  Six  Sigma,  and  other  methodologies — management  sponsors  and 
champions,  line  and  support  management  directly  affected  by  such  changes,  process  group  leads 
and  members  responsible  for  implementing  such  changes,  and  the  team  leaders  and  developers 
enacting  such  new  methods  in  concert  and  combination  with  their  existing  practices.  This  guide  is 
not  exhaustive;  rather  it  is  a  starting  point  on  the  road  to  using  CMMI  and  related  technologies  to 
help  organizations  achieve  business  objectives  using  world-class  process  management  techniques. 
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Structure  and  How  To  Use  This  Document 


Section  1  of  this  report  provides  a  context  for  and  a  general  description  of  AIM  and  its 
components.  Section  2  describes  a  series  of  overlapping  role-based  “execution  threads”  for  AIM 
usage;  the  roles  are  those  typically  found  in  an  organization  implementing  AIM.  Section  3 
provides  specific  guidance  to  process  and  development  groups  on  AIM  implementation  issues  that 
they  are  likely  to  face.  Four  appendices  are  included.  Appendix  A  contains  a  series  of  process 
flow  diagrams  tying  together  specific  roles  and  activities  for  certain  process  elements  of  TSP+, 
the  main  implementation  component  of  AIM.  Appendix  B  contains  a  few  important  process 
elements  in  TSP+.  Appendix  C  contains  sample  templates  from  the  GQ(I)M  paradigm  that  is 
central  to  Goal  Driven  Measurement,  as  described  in  a  course  taught  at  the  Software  Engineering 
Institute1,  and  in  several  SEI  publications  [Park  1996,  Goethert  2004].  Appendix  D  is  a  series  of 
Process  Improvement  Proposals  (PIPs)  that  were  used  to  identify  gaps  in  CMMI  coverage  in 
previous  versions  of  TSP. 

We  recommend  the  following  sections  of  this  report  for  our  readers: 

•  for  management  sponsors  and  champions,  all  of  Section  1  and  at  least  Sections  2.1,  2.2,  and 

2.6 

•  for  line  and  support  management,  all  of  Sections  1  and  2 

•  for  most  process  group  leads  and  members,  the  entire  report  excluding  Appendix  D,  with 
special  attention  to  Section  2  and  parts  of  Section  3  and  Appendices  A,  B,  and  C  as  needed, 
in  addition  to  the  Guide  for  SCAMPI  Appraisals:  Accelerated  Improvement  Method  (AIM) 
[Miluk  2010] 

•  for  development  team  leaders  and  members,  Sections  1  and  2,  plus  specific  parts  of  Section  3 
and  Appendices  A,  B,  and  C  as  needed 

•  in  addition  to  the  above,  for  process  groups  and  development  teams  with  prior  TSP 
experience,  Appendix  D. 


1  Implementing  Goal-Driven  Measurement,  http://www.sei.cmu.edu/training/p06.cfm. 
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1  Introduction  to  the  Accelerated  Improvement  Method  (AIM) 


This  report  describes  the  Accelerated  Improvement  Method  (AIM),  a  rapid  deployment  of  high- 
performance  CMMI  practices — the  Team  Software  Process  (TSP),  tailored  SCAMPI  appraisals,  and 
elements  of  Six  Sigma — as  the  core  technologies  of  an  approach  that  addresses  maturity  levels  2  and 
3,  and  provides  significant  support  for  the  higher  maturity  levels.  This  approach  builds  upon  field 
experience  by  SEI  staff,  client  organizations,  and  others  that  have  recognized  the  potential  in  using 
these  technologies  together.  CMMI  provides  an  organizational  “what-to-do”  viewpoint,  while  the 
other  practices  bring  organizational,  project  team,  and  individual  “how-to-do-it”  viewpoints  as  well  as 
critical  feedback,  with  the  following  features. 

•  The  approach  allows  more  rapid  implementation  than  CMMI  norms,  hence  “Accelerated 
Improvement  Method,”  or  “AIM.”  The  nominal  AIM  timeframe  for  a  small-to-medium-sized 
development  organization  to  achieve  CMMI  maturity  level  3  is  1 8  months,  or  less  than  half  the 
time  normally  attributed  to  the  IDEAL -based  improvement  approach. 

•  The  AIM  approach  achieves  excellent  results  in  terms  of  measureable  project  performance 
improvements,  beginning  with  the  first  project.  Predictable  schedule  and  costs  with  a  30% 
improvement  in  productivity  and  80%  fewer  delivered  defects  are  common  results.  Initial  pilot 
projects  can  begin  within  weeks  of  a  decision  to  proceed. 

•  CMMI  implementation  proceeds  on  a  project-by-project  basis,  rather  than  using  a  maturity  level 
(ML)  or  process  area  (PA)  approach,  although  certain  groupings  of  PAs  are  naturally  addressed 
by  AIM.  The  project-by-project  approach  assures  constrained,  identifiable,  and  incremental 
costs,  with  measureable  results  that  justify  those  costs. 

•  AIM  provides  a  path  to  sustain  and  improve  upon  excellent — and  in  some  cases,  world-class — 
results,  while  building  the  internal  capability  to  support  the  new  way  of  working. 

AIM  thus  addresses  the  ongoing  debate  in  the  CMMI  community  of  performance  vs.  compliance. 
Does  an  organization  implementing  CMMI  target  the  achievement  of  a  particular  CMMI  maturity 
level?  Or  does  the  organization  instead  use  CMMI  as  a  guide  for  improving  perfonnance  in  terms  of 
critical  business  measures  such  as  cost,  schedule,  and  quality?  AIM  recognizes  that  framing  the 
debate  as  an  either-or  proposition  creates  a  false,  perhaps  even  dangerous,  choice,  and  instead  affirms 
that  an  organization  can  and  must  do  both  to  gain  maximum  advantage  from  any  such  technology 
investment. 

However  one  chooses  to  frame  this  debate,  and  whatever  method  one  might  employ,  CMMI 
implementations  generally  face  multiple  related  issues  that  influence  the  choices  that  organizations 
make  when  implementing  CMMI.  How  much  will  this  improvement  effort  cost?  How  long  will  it 
take?  How  much  better  will  the  organization’s  performance  be  once  a  certain  CMMI  maturity  level  is 
achieved?  What  is  this  change  in  performance  worth  to  the  business?  What  must  happen  to  sustain 
these  changes  once  they  are  made?  AIM  provides  answers  to  these  questions  based  on  customer 
experience  not  on  academic  projections. 

1.1  The  Need  for  AIM 

Many  CMMI  improvement  efforts  rely  to  some  extent  on  the  IDEAL  change  model  [McFeeley  1996]. 
IDEAL  dates  back  at  least  to  the  early  1 990s  when  it  was  associated  with  implementing  the  original 
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CMM  for  Software,  or  SW-CMM  [Paulk  1994],  Newcomers  to  CMMI-based  improvement  inevitably 
leam  IDEAL  principles  since  it  is  the  one  change  management  approach  mentioned  in  the  standard 
SEI  Introduction  to  CMMI  training.  But  this  also  implies  that  newcomers  almost  inevitably  accept  the 
historical  assumptions  and  limitations  built  into  many  early  IDEAL  implementations,  especially  the 
inherited  staged-model  mindset  of  the  SW-CMM. 

Assuming  that  SEI  data  is  reflective  of  early  improvement  approaches,  the  semi-annual  CMMI 
Maturity  Profile  exposes  some  of  those  limitations.  One  such  historical  limitation  is  that  CMMI 
(staged)  implementation  almost  necessarily  proceeds  maturity  level  by  maturity  level,  and  associated 
with  that  procession  is  an  average  of  one  to  two  years  elapsed  time  per  level  [SEI  2010].  The 
improvements  from  the  earlier  Software  Maturity  Profile  based  on  the  SW-CMM,  most  notably  a 
reduction  in  the  time  from  ML1  to  ML2  (from  19  months  average  over  175  instances,  to  4.5  months 
average  for  just  6  instances),  are  probably  due  to  most  companies  starting  on  this  path  not  bothering  to 
pay  for  an  appraisal  that  they  expect  to  show  ML1.  This  is  evidenced  by  the  very  small  number  of 
“official”  MLl-to-ML2  transitions. 

Paradoxically  some  of  IDEAL’s  limitations  are  due  to  the  fact  that  it  is  a  generic  model  for 
improvement  and  change.  IDEAL  makes  few  (if  any)  assumptions  either  about  where  an  organization 
begins  or  about  what  methods  it  uses.  As  such,  even  the  best  of  implementations  can  require  a  lot  of 
time  to  gather  data,  survey  a  situation,  set  goals,  and  build  a  plan  of  attack.  Lacking  specific  guidance 
on  methods,  or  when  the  “one-to-two-years-per-level”  mindset  colors  planning  assumptions,  an 
improvement  team  such  as  a  process  group  (PG)  can  consume  many  months  acquiring  or  developing 
this  information.  In  contrast,  the  AIM  approach  uses  known,  trainable  methods  with  known 
performance  characteristics,  and  which  seem  to  work  in  a  wide  variety  of  development  enviromnents. 

1.2  What  is  AIM? 

AIM  is  composed  of  five  key  elements  that  work  together  to  accomplish  its  goals. 

1 .  a  strategy  of  rapid  deployment,  project  team  by  project  team 

2.  the  current  version  of  CMMI-DEV,  in  particular  the  specific  and  generic  goals  and  practices  at 
maturity  levels  2  and  3,  as  the  reference  model  of  best  practices  [CMMI-DEV  2010] 

3.  the  Team  Software  Process  (TSP)  [Humphrey  2000],  beginning  with  training  in  the  Personal 
Software  Process  (PSP)  [Humphrey  1995],  which  provides  project  teams  and  individuals, 
including  the  process  group  (PG),  with  a  transparent  operational  framework  of  process, 
measurement,  and  management  practices  consistent  with  CMMI 

4.  tailored  SCAMPI  appraisals  [SCAMPI  2006b],  guided  by  the  Guide  for  SCAMPI  Appraisals: 
Accelerated  Improvement  Method  (AIM)  [Miluk  20 1 0]  which  provides  standard  SCAMPI-C 
reference  information  to  practitioners  and  appraisers,  one  or  more  targeted  SCAMPI  B/C  events 
at  intermediate  points  during  implementation,  and,  if  desired,  a  SCAMPI  A  [SCAMPI  2006a]  to 
verify  maturity  level  attainment 

5.  methods  from  the  Six  Sigma  discipline  for  analyzing  operational  data  and  then  identifying  and 
acting  upon  improvement  opportunities  [Motorola  20 1 0] 

These  five  elements  blend  together  to  produce  superior  results,  beginning  from  the  first  pilot  project 
through  deployment  across  the  organization. 


CMU/SEI-2010-SR-032  |  2 


1.2.1  Rapid  Deployment 


The  logic  for  AIM  rapid  deployment  proceeds  as  follows. 

1 .  Use  proven  methods  with  known  perfonnance  characteristics  (TSP,  CMMI,  SCAMPI,  and  Six 
Sigma). 

2.  Characterize  current  performance  and  gather  information  on  existing  process  assets. 

3.  Train  developers  and  their  direct  managers  quickly  in  TSP  methods  on  a  project-by-project  basis. 
In  parallel,  train  PG  and  other  involved  personnel  in  TSP  and  CMMI  as  appropriate. 

4.  Identify  pilot  projects  and  launch  each  project  as  a  TSP  team  as  soon  as  training  for  the  team  is 
complete.  One  of  the  early  teams  trained  and  launched  this  way,  although  preferably  not  the  first, 
is  the  organization’s  process  group  (PG). 

5.  Gather  data  on  both  perfonnance  and  conformance  (the  latter  through  a  tailored  SCAMPI  B 
appraisal),  and  make  adjustments  as  each  new  project  is  trained  and  launched. 

6.  Use  data  and  experience  from  early  pilots  to  plan  and  implement  broader  adoption  within  the 
organization.  Introduce  Six  Sigma  training  and  techniques  as  appropriate. 

7.  If  necessary,  confirm  CMMI  compliance  with  a  SCAMPI  A  appraisal. 

Even  the  smallest  organizations  can  take  advantage  of  early  projects  to  expose  potential  internal 
experts  to  the  various  technologies.  Building  internal  capability  is  crucial  to  the  long-term  viability  of 
these  techniques  in  any  organization. 

1.2.2  CMMI 

CMMI,  including  its  predecessor  CMM  for  Software,  is  probably  the  most  widely  used  family  of 
improvement  models  for  the  development  of  software  and  software-intensive  systems.  As  a  model  of 
best  practices,  CMMI  describes  characteristics  of  such  practices,  and  though  examples  of 
implementation  techniques  are  numerous,  by  design  the  model  itself  avoids  any  recommendations  of 
how  one  should  design  and  implement  such  practices.  The  intent  of  AIM  is  to  provide  just  such  a  set 
of  recommendations,  though  not  an  exclusive  set. 

For  example,  CMMI  does  not  specify  an  appraisal  method,  stating  only  that  one  should  “appraise  the 
organization’s  processes  periodically  and  as  needed  to  maintain  an  understanding  of  their  strengths 
and  weaknesses”  (OPF-SP1.2  CMMI-DEV  VI. 2).  SCAMPI  appraisals  are  most  commonly  used  for 
formal  appraisal  in  this  regard.  Many  others — some  adapted  from  SCAMPI  or  other  techniques,  some 
home-grown — are  used  both  formally  and  informally,  and  often  in  conjunction  with  SCAMPIs  of  one 
flavor  or  another,  in  order  to  implement  the  intent  of  the  model.  AIM  specifies  the  formal  use  of 
tailored  SCAMPI  appraisals  in  several  modes,  but  other  techniques  can  and  should  be  used  to 
supplement  such  activities. 

AIM’s  scope  with  respect  to  CMMI  is  limited  and  specific:  CMMI-DEV  V.1.2  maturity  level  3, 
excluding  Supplier  Agreement  Management  (SAM).  However,  this  scope  does  not  imply  that  one 
cannot  implement  SAM  or  higher  maturity  processes  within  AIM,  only  that  AIM  practices  make  no 
specific  claim  that  they  implement  any  of  that  PA’s  practices. 

This  also  does  not  imply  that  AIM  might  somehow  become  obsolete  with  the  next  version  of  CMMI- 
DEV,  or  even  that,  for  example,  one  should  avoid  attempts  to  implement  CMMI-SVC  practices  using 
AIM.  As  of  this  writing,  CMMI  V.1.3  is  in  its  final  stages  of  development,  with  minimal  changes  at 
maturity  levels  2  and  3.  Furthermore,  the  “constellation”  architecture  of  the  CMMI  models  specifies 
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16  of  the  22  PAs  in  CMMI-DEV  as  “core  PAs”  that  are  common  to  CMMI-DEV,  CMMI-SVC 
(CMMI  for  Services),  and  CMMI-ACQ  (CMMI  for  Acquisition),  12  of  those  at  ML3.  All  12  core  PAs 
are  within  the  scope  of  AIM,  as  well  as  the  structure  provided  by  all  12  generic  practices  at  capability 
levels  2  and  3  that  are  common  to  all  PAs,  perhaps  making  AIM  a  good  starting  point  to  address  not 
only  CMMI-DEV  (the  current  focus)  but  CMMI-SVC  and  CMMI-ACQ  as  well. 

1.2.3  TSP:  Team  Software  Process 

As  implied  by  its  name,  the  Team  Software  Process  component  of  AIM  deals  directly  with  the  most 
generic  units  of  implementation — project  teams  and  their  members.  In  some  sense,  the  most 
fundamental  objective  of  CMMI  is  to  improve  the  performance  of  project  teams  by  changing  the 
behavior  of  those  teams’  individual  members.  Beginning  with  training  in  the  Personal  Software 
Process  (PSP)  and  carrying  over  into  actual  development  projects,  TSP  team  members  implement  a 
task-oriented  framework  of  processes  and  management  and  measurement  frameworks  that  provide 
ongoing  performance  feedback  to  both  the  individual  and  the  team.  This  approach  enables  rapid  and 
profound  changes  in  behavior,  as  reflected  by  measured  performance  improvements. 

PSP  and  TSP  were  designed  to  guide  not  only  software  development,  but  any  structured  intellectual 
activity.  For  example,  TSP  has  been  adapted  for  use  in  the  development  of  video  games,  for  which  a 
typical  team  includes  game  designers,  graphic  designers,  writers,  artists,  and  musicians,  all  of  whom 
outnumber  the  software  developers  [Bala  2007],  PSP  and  TSP  principles  have  also  been  used  to  create 
most  of  the  training,  presentation,  and  print  materials  used  to  spread  TSP  knowledge.  As  of  this 
writing,  TSP  pilot  projects  exist  for  services  applications  and  for  development  teams  using  SEI 
architecture  methods.  All  of  these  are  in  addition  to  the  expected  uses  for  TSP  in  more  traditional 
software  development  venues  such  as  banking  and  finance,  industrial  and  embedded  control  systems, 
shrink-wrapped  software,  and  IT  applications. 

TSP  has  been  in  use  for  over  10  years  with  excellent  results  [Sasao  2010,  Nichols  2009,  Wall  2007, 
Davis  2004].  Capers  Jones  recently  identified  TSP/PSP  as  one  of  the  top  development  methods  in  use 
today  across  small,  medium,  and  large  systems,  and  in  fact,  is  the  only  method  that  ranked  either  first 
or  second  in  all  project  size  categories  [Jones  2009].  TSP’s  built-in  performance  measurement 
framework  is  used  continuously  to  verify  implementation  and  to  identify  opportunities  for  further 
improvement. 

1.2.4  SCAMPI 

As  mentioned  above,  SCAMPI  appraisals  are  a  key  component  of  AIM  implementation.  If  necessary, 
an  early  SCAMPI  B/C  appraisal  may  be  used  to  survey  organizational  practices.  At  intermediate 
stages,  SCAMPI  B/C  is  used  to  verify  implementation  of  other  AIM  practices,  to  identify  both 
potential  weaknesses  to  be  corrected  and  unique  adaptations  that  have  the  potential  to  improve  the 
common  practice,  and  also  to  verify  that,  where  AIM  and  organizational  practices  have  combined, 
those  combinations  are  CMMI -compliant. 

To  verify  the  attainment  of  a  particular  CMMI  maturity  level,  the  only  official  option  is  the  SCAMPI 
A  appraisal  led  by  an  SEI-certified  Lead  Appraiser.  The  Guide  for  SCAMPI  Appraisals:  Accelerated 
Improvement  Method  (AIM)  provides  a  practice-by-practice  breakdown  of  expected  AIM  artifacts 
through  CMMI  maturity  level  3  [Miluk  2010],  These  artifacts  are  the  expected  results  of  TSP 
implementation,  without  consideration  of  any  other  valuable  practices  that  might  exist  on  a  team  or  in 
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an  organization.  Obviously,  these  expectations  should  be  adjusted  based  on  an  organization’s 
particular  implementation,  as  well  as  the  results  of  any  intermediate  SCAMPI  B/C  appraisals. 


1.2.5  Six  Sigma 

Six  Sigma  methods  have  a  documented  history  of  use  in  CMMI-based  improvement,  especially  for  the 
attainment  of  higher  maturity  levels  [EB  2008,  Habib  2008,  Siviy  2008,  Siviy  2005].  However,  the 
use  of  these  methods  in  AIM  is  not  to  address  CMMI  maturity  levels  4  and  5,  but  rather  to  provide  a 
framework  for  evaluating  the  often  voluminous  data  provided  by  TSP  teams,  and  to  then  take  action 
on  the  opportunities  presented  by  that  data. 

The  Six  Sigma  concentration  on  the  Voice  of  the  Customer  (VoC)  is  usually  the  most  immediately 
useful  method  within  the  AIM  framework.  In  addition  to  the  obvious  use  in  Requirements 
Development  (RD)  and  Validation  (VAL)  within  CMMI,  VoC  is  a  valuable  tool  for  eliciting 
stakeholder  needs  in  preparation  for  a  TSP  launch.  Beyond  that,  Six  Sigma  deployment  typically 
proceeds  after  some  significant  number  of  teams  and  projects  have  completed  cycles  and  projects  in 
an  organization.  Both  DMAIC  (Define,  Measure,  Analyze,  Improve,  Control)  and  DFSS  (Design  for 
Six  Sigma)  methods  are  useable  within  AIM.  The  general  recommendation  is  to  begin  with  DMAIC 
unless  an  experienced  Six  Sigma  Black  Belt  is  available  to  lead  DFSS  efforts. 

1.3  How  Does  AIM  Work? 

While  the  five  major  AIM  components  must  work  together  and  be  balanced  properly  for  any  particular 
organization,  it  is  fair  to  say  that  TSP  implementation  is  the  key  to  AIM  effectiveness.  By  themselves, 
TSP  practices  address  a  large  majority  of  CMMI  specific  practices.  In  addition,  there  are  five 
significant  distinguishing  features  of  the  TSP  which,  while  consistent  with  CMMI  practices,  go 
significantly  beyond  the  requirements  of  the  model.  The  total  effect  of  these  practices  is  to  approach 
the  CMMI  ideal  of  the  right  functionality  delivered  defect-free,  on  time,  and  on  budget.  These  TSP 
features  are: 

1 .  Personal  Software  Process  (PSP)  training 

2.  TSP  measurement  framework 

3.  TSP  coaching  and  self-directed  teams 

4.  comprehensive  life-cycle  quality  practices 

5.  a  project-team-focused  improvement  strategy 

These  features  reflect  the  view  that  software-intensive  systems  are  produced  by  knowledge  work.  As 
Watts  Humphrey  observed,  the  primary  rule  for  managing  knowledge  work  is  that  managers  can’t 
manage  it;  the  workers  must  manage  themselves.  In  order  to  manage  their  own  work,  software- 
intensive  development  teams  must  be  motivated  properly,  make  their  own  plans,  negotiate  their  own 
commitments,  track  these  plans  and  commitments,  and  manage  their  own  quality.  These  five  features 
of  TSP  are  essential  for  its  use  by  and  integration  into  AIM.  Therefore,  it  is  essential  that  those 
implementing  AIM  understand  something  of  these  features. 

1.3.1  TSP  Training — The  Personal  Software  Process  (PSP) 

It  is  fair  to  say  that  TSP,  the  Team  Software  Process,  would  not  exist  without  PSP,  the  Personal 
Software  Process.  PSP  development  preceded  that  of  TSP  by  several  years  [Humphrey  2000],  But 
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more  than  that,  both  in  philosophy  and  in  operational  detail,  PSP  training  and  practices  are 
foundational  to  TSP. 

PSP,  as  the  full  name  implies,  teaches  process  skills  at  the  individual  level.  PSP  is  taught  as  a  series  of 
progressively  more  comprehensive  operational  development  processes,  beginning  with  a  “plain 
vanilla”  framework  usable  by  any  competent  software  developer,  with  basic  measurements  of  time 
and  defects.  Developers  write  a  series  of  small  programs,  gathering  data  along  the  way  on  their  own 
performances,  adding  size  measurement  and  estimation  practices,  test  and  design  documentation, 
personal  reviews,  and  personal  planning  (a  partial  list).  Each  of  the  PSP  practices  are  used,  relied 
upon,  or  built  upon  in  the  TSP. 

1.3.2  TSP  Measurement  Framework 

The  TSP  measurement  framework  is  the  first  obvious  way  in  which  TSP  builds  upon  PSP  skills. 
Strictly  speaking,  TSP  measurement  adds  no  new  data  to  the  set  specified  by  PSP  (tune  on  task, 
defects,  product  size,  and  task  completion  date).  However,  dates  are  not  used  in  any  substantive  way 
in  the  PSP  training,  whereas,  of  course,  they  are  critical  to  most  real-world  projects. 

These  basic  data  requirements  pre-date  the  PSP,  finding  their  source  in  the  early  days  of  SEI 
measurement  research  [Carleton  1992],  Unique  to  TSP,  these  data  originate  with  individual 
developers  in  real-time.  The  data  then  aggregate  at  the  team  level,  and  are  used  at  least  weekly  for  the 
purposes  of  project  and  quality  management,  both  by  the  project  team  collectively  and  by  the  team 
members  individually.  Thus,  the  measurement  framework  provides  enormous  leverage  to  project 
teams  to  manage  their  own  work  and  their  own  projects,  and  to  the  teams,  projects,  and  organization 
as  a  whole  to  analyze  and  improve  process  performance. 

The  questions  about  what  data  to  report  to  what  layer  of  management,  and  how  often  to  report,  are,  of 
course,  questions  that  must  be  answered  by  any  CMMI  effort.  In  TSP,  however,  this  becomes  more  a 
question  of  how  to  store,  select,  and  summarize  data,  rather  than  the  more  usual  case  of  having  to 
figure  out  what  data  to  collect  and  how  to  collect  it  in  the  first  place.  Another  SEI  technology,  Goal- 
Driven  Measurement  (GDM)  [Park  1996],  which  is  also  a  descendant  of  the  original  SEI  measurement 
research,  may  be  useful  within  this  context  as  well,  by  providing  documented  coverage  of  CMMI 
Measurement  and  Analysis  (MA)  practices  [Goethert  2004]  and  a  convenient  way  to  summarize  TSP 
measurement  usage  within  an  organization  (see  Appendix  C). 

1.3.3  TSP  Coaching  and  Self-Directed  Teams 

TSP  teams  are  self-directed,  but  this  does  not  mean  that  there  is  no  identified  leader  of  the  team.  The 
TSP  team  leader  is  designated  by  and  responsible  to  the  management  chain,  just  as  in  more  traditional 
authority  structures.  However,  TSP  is  based  on  the  idea  that  because  software  is  knowledge  work, 
such  knowledge  work  can  be  managed  effectively  only  by  the  people  who  are  doing  the  work.  The 
structure  of  the  TSP  team  thus  is  not  the  traditional  one  with  a  team  leader  exerting  a  command-and- 
control  management  style,  but  rather  one  that  recommends  a  more  egalitarian  approach  with  the  team 
leader  as  a  first-among-equals  directing  and  coordinating  the  team. 

Self-directed  TSP  teams  rely  on  their  PSP  skills  and  the  TSP  measurement  framework  to  plan  and 
track  their  own  work,  usually  more  effectively  than  with  “traditional”  team  leadership.  The  most 
visible  vehicle  for  planning  is  the  TSP  launch,  an  intense  series  of  meetings  lasting  from  one  to  five 
days,  depending  on  the  size  and  number  of  team  members  and  project  teams  involved,  as  well  as  on 
the  scope  and  duration  of  the  project. 


CMU/SEI-2010-SR-032  |  6 


Figure  1:  TSP  Launch  Meetings  (Source:  [Humphrey  2010]) 

During  a  launch,  a  TSP  team  chooses  team  roles,  defines  its  own  objectives  for  achieving  management 
goals,  identifies  work  products,  defines  a  technical  strategy,  selects  or  defines  a  development  process, 
and  builds  both  an  overall  plan  for  the  project  and  a  detailed  near-term  plan  (down  to  the  level  of 
several  weekly  tasks  for  the  individuals  on  the  team).  The  TSP  team  also  identifies  and  evaluates  risks 
to  the  plan,  prepares  a  briefing  report  for  management,  and  then  presents  the  plan  to  management  for 
negotiation  and  approval.  After  the  launch,  the  team  generates  weekly  reports  of  the  data  that  they 
collect  using  the  measurement  framework  (both  individually  and  aggregated  as  a  team),  and  uses  the 
data  to  track  progress  and  risks  and  to  identify  and  respond  to  issues  proactively,  including  replanning 
as  necessary.  All  of  these  activities  are  recognizable  practices  within  various  CMMI  Project 
Management  PAs. 

While  effective  TSP  team  leaders  are  often  effective  coaches  to  their  teams,  the  TSP  defines  a  separate 
role  for  a  designated  coach.  The  TSP  coach  is  critical  to  the  success  of  the  self-directed  team  in  the 
launch,  periodic  relaunches,  and  execution  of  the  project.  The  role  of  the  coach  is  perhaps  best 
explained  by  analogy  to  sports  teams.  A  coach  typically  does  not  take  the  field,  but  rather  focuses — 
especially  before  and  after  the  game — on  the  skills  and  processes  used  by  the  team  and  its  members. 
While  it  was  originally  thought  that  the  need  for  an  independent  coach  would  diminish  as  a  team 
leader  gained  experience  with  TSP  methods,  in  practice,  launches  and  relaunches  (at  a  minimum) 
seem  to  demand  an  independent  process  expert  role  that  cannot  be  filled  effectively  by  the  team 
leader,  especially  for  larger  teams.  One  notes,  however,  that  an  effective  team  leader  seems  to  be  able 
to  function,  at  least  in  routine  situations,  as  a  coach  outside  of  the  launch  environment,  allowing  scarce 
TSP  coaches  to  extend  their  circle  of  influence  more  widely. 

1.3.4  Comprehensive  Quality  Management 

Both  CMMI  and  TSP  have  their  roots  in  the  manufacturing  quality  movement.  The  fundamental  idea 
that  rework  is  waste  that  can  be  measured  and  intelligently  reduced  goes  back  at  least  as  far  as  Dr. 
Walter  Shewhart  [Shewhart  1980]  (originally  published  in  193 1),  and  carries  on  through  the  work  of 
W.  Edwards  Deming  [Deming  1982],  Philip  Crosby  [Crosby  1980],  and  many  others.  The  idea  was 
used  by  Watts  Humphrey  and  his  colleagues  at  IBM  to  address  software  quality  issues;  he  brought  this 
with  him  when  he  founded  the  SEl’s  Software  Engineering  Process  Management  (SEPM)  program  in 
1986  and  led  the  development  of  the  original  CMM  for  Software.  The  formulation  of  Total  Quality 


CMU/SEI-2010-SR-032  |  7 


Management  (TQM)  [Deming  1982]  and  Six  Sigma  practices  [Motorola  2010] — other  systems  of 
practice  derived  from  manufacturing  quality  ideas — was  also  underway  in  this  same  general  period. 

The  systematic  identification  and  elimination  of  waste  underlies  the  fact  that  “faster,  better,  cheaper” 
is  not  so  much  a  choice  of  alternatives  as  a  recipe  for  improvement.  In  other  words,  while  one  might 
be  able  to  choose  “faster”  or  “better”  or  “cheaper”  at  the  expense  of  one  or  both  of  the  others,  there  is 
almost  always  a  way  to  choose  “better”  that  is  also  “faster”  and  “cheaper.”  Significantly  in  software, 
the  ways  that  are  at  once  better,  faster,  and  cheaper  can  be  known  and  implemented  only  by  those  who 
actually  perform  the  work  in  question — that  is,  by  the  knowledge  workers  themselves.  This  idea  is 
fundamental  to  AIM  methods  and  results. 

When  TSP  teams  produce  overall  and  detailed  plans  in  a  launch,  they  don’t  just  plan  what  to  do,  they 
also  plan  how  well  they  are  going  to  do  it — when  they  are  likely  to  inject  defects  and  how  many,  when 
they  are  likely  to  discover  and  remove  those  defects,  and  how  many  defects  will  leak  through  the  final 
stages  of  integration  and  testing,  and  ultimately  will  be  delivered  to  the  customer.  This  planning  and 
its  subsequent  execution  is  not  a  utopian  exercise  dedicated  to  some  impossible  ideal  of  perfection,  but 
rather  a  hard-nosed  business  practice  that  recognizes  that  the  largest  variations,  and  therefore  the 
largest  controllable  costs  and  some  of  the  biggest  project  risks,  are  embedded  in  the  issue  of  quality. 

The  theme  of  quality  management  is  woven  throughout  the  various  threads  of  the  CMMI-TSP-Six 
Sigma  tapestry.  In  PSP  training,  every  defect  found  is  cataloged  and  later  analyzed  for  use  in  building 
and  updating  review  checklists.  The  defect  density  in  test  and  the  amount  of  time  spent  finding  and 
fixing  defects  in  test  (i.e.,  rework)  are  primary  indicators  of  both  product  and  process  quality.  This 
idea  is  carried  through  intact  into  the  TSP  measurement  framework,  and,  as  mentioned  previously,  is  a 
primary  focus  of  self-directed  team  planning,  execution,  and  coaching  throughout  the  development 
life  cycle. 

When  enough  data  accumulates  across  projects  to  define  relationships  between  effort,  schedule,  and 
quality,  Six  Sigma  methods  analyze  those  relationships  by  looking  for  opportunities  to  make  process 
changes  that  will  improve  performance  across  all  projects.  These  changes  can  take  the  form  of 
eliminating  common  issues  with  current  process  execution  (for  example,  by  formalizing  the  different 
perspectives  to  be  covered  in  a  design  inspection)  or  by  modeling  or  piloting  the  use  of  a  new  tool  or 
method  (which  can  be  as  trivial  as  specifying  the  use  of  a  hitherto  unused  feature  in  an  existing 
development  enviromnent,  or  as  substantial  as  specifying  a  method  for  architectural  design). 

1.3.5  Project  Team-Focused  Improvement  Strategy 

Many  CMMI  implementation  efforts  attempt  to  move  an  entire  organization  up  the  maturity  ladder 
level  by  level,  or  perhaps  PA  by  PA  in  slightly  more  enlightened  instances.  Part  of  the  rationale  for 
this  “lock-step”  approach  is  that  moving  one  part  of  an  organization  very  far  above  another  can  result 
in  organizational  dysfunction,  for  example,  by  imposing  different  operational  requirements  upon  other 
otherwise  similar  projects,  or  by  having  closely  cooperating  projects  working  in  dissimilar  ways.  The 
TSP  approach,  as  depicted  in  Figure  2,  is  to  move  entire  projects  to  new,  more  efficient  behaviors 
representing  significantly  higher  maturity  levels  very  rapidly. 
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Figure  2:  Project  Team  Implementation  Cycles 

The  experience  of  TSP  projects  in  organizations  at  all  maturity  levels  is  that  the  potential  issues 
related  to  this  approach  are  easily  managed,  for  four  reasons.  First,  pilot  projects  by  definition  are 
trying  something  new  in  the  organization,  and  clear  communications  concerning  what  is  being 
attempted  and  why  typically  result  in  a  willingness  to  accommodate  necessary  changes,  at  least  on  a 
trial  basis.  Second,  because  TSP  and  now  AIM  offer  an  operational  system  of  practices,  the  critical 
internal  interfaces  required  for  smooth  project  operation  are  well-defined.  A  third  and  related  reason  is 
that  TSP  mechanisms  are  also  defined  for  multiple  team  projects,  so  that  dealing  with  interface  issues 
in  such  cases  does  not  require  case-by-case  definition.  Finally,  because  TSP  is  a  defined  and  measured 
operational  system,  each  project  serves  as  an  example  of  model  behavior,  not  to  mention  potentially 
exemplary  results. 

The  project  team  focus  is  the  key  factor  enabling  the  rapid  deployment  that  is  a  hallmark  of  AIM.  A 
significant  majority  of  CMMI  practices  are  project-level  practices.  In  AIM,  many  of  the  practices  that 
apply  to  organizational  activities  are  implemented  by  the  PG  team.  Thus,  by  training  and  launching 
team-by-team  as  quickly  as  training  resources  and  project  cycles  permit,  and  by  including  the  PG  as 
one  of  those  teams,  maximum  diffusion  of  AIM  methods  is  achieved  in  minimum  time. 
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2  Using  AIM 


Many  who  wish  to  use  the  AIM  technologies  only  want  to  know  one  thing — what  to  do.  This  section 
describes  six  overlapping  execution  threads  that  generally  begin  in  the  order  presented,  then  run  in 
parallel  with  one  another  over  the  course  of  months  and  years  as  an  organization  adopts  these  methods 
and  adapts  them  for  use  in  its  unique  circumstances.  Although  each  thread  is  described  separately 
here,  various  threads  constantly  interact  during  the  course  of  AIM  introduction  and  ongoing  execution, 
as  will  become  apparent  in  the  following  descriptions. 

The  AIM  execution  threads  are: 

1 .  Securing  and  maintaining  executive  sponsorship 

2.  Characterizing  current  and  future  capability  and  performance 

3.  Identifying,  training,  and  launching  pilot  projects 

4.  Identifying,  training,  and  launching  the  PG 

5.  Evaluating  pilot  projects  and  planning  further  rollout 

6.  Building  a  culture  of  excellence  and  continuous  improvement 

2.1  Securing  and  Maintaining  Executive  Sponsorship 

One  way  in  which  AIM  is  very  like  other  improvement  initiatives  is  in  its  need  for  executive 
sponsorship.  Sponsorship  demonstrates  explicit  interest  on  the  part  of  senior  management  to  create 
and  sustain  an  organization  that  exhibits  the  high-performance  characteristics  of  TSP  teams  using 
methods  that  will  be  recognized  as  CMMI-compatible  by  a  competent  SCAMPI  appraisal  team.  For 
AIM,  serious  interest  is  signaled  by  attendance  at  one-day  seminars  such  as  Implementing  CMMIfor 
High  Performance2  or  the  TSP  Executive  Seminar3 . 

Each  seminar  conveys  some  of  the  information  in  the  present  document  as  it  builds  the  case  for 
implementing  CMMI  according  to  these  recommendations.  When  presented  at  a  customer  site,  a 
seminar  is  often  coupled  with  a  half-day  planning  session  that  begins  the  process  of  formulating 
specific,  measureable  goals  for  the  AIM  efforts,  identifying  any  relevant  baseline  information  in  the 
organization,  and  identifying  likely  candidates  for  pilot  projects  and  the  PG. 

However,  active  participation  in  such  a  seminar  or  funding  a  proposal  to  implement  AIM  is  ultimately 
not  enough  to  demonstrate  management’s  commitment  to  these  methods.  It  is  their  ongoing 
involvement  in  these  efforts  that  ultimately  signals  to  the  organization,  “This  is  how  we  do  things 
now.”  Sustaining  sponsorship  can  be  seen  in  at  least  two  ways:  thoughtful  policy  statements  (both 
official  and  infonnal),  and  regular  reviews.  It  is  no  accident  that  each  of  these  are  reflected  in  CMMI 
generic  practices  GP  2.1  “Establish  an  Organizational  Policy”  and  GP  2.10  “Review  Status  with 
Higher  Level  Management,”  which  apply  to  every  process  area  in  the  CMMI. 

The  AIM  recommendation  is  started  with  a  very  broad  policy  statement  from  management  that 
indicates  the  general  direction  in  which  the  organization  is  heading  over  the  next  several  months  and 


2  Implementing  CMMI  for  High  Performance,  an  Executive  Seminar,  http://www.sei.cmu.edu/traininq/p22b.cfm. 

3  TSP  Executive  Strategy  Seminar,  http://www.sei.cmu.edu/traininq/p22.cfm. 
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years  with  respect  to  disciplined  practices  in  the  areas  of  the  CMMI  process  categories — project 
management,  process  management,  engineering,  and  support  activities.  As  the  pilot  projects  and  PG 
work  begins  to  instantiate  AIM  practices  within  the  organization  and  these  results  are  reviewed  with 
senior  management,  more  specific  policies  tailored  to  the  organization’s  best  results  are  crafted, 
usually  by  the  PG,  but  always  with  strong  input  from  project  personnel.  In  other  words,  the  people 
most  affected  by  the  policies  (guiding  their  use  of  these  methods)  will  write  those  policies,  while 
regular  reviews  of  the  results  from  usage  experience  will  explain  and  justify  the  policies  for  senior 
management  to  approve  and  then  advocate  across  the  organization. 

2.2  Characterizing  Current  and  Future  Capability  and  Performance 

When  formulating  specific  performance  goals  for  almost  any  endeavor,  the  question  usually  arises: 
Compared  to  what?  “Increase  productivity  by  50%, ”  “Reduce  delivered  defects  by  50%, ”  and 
“Decrease  cycle  time  by  20%” — all  performance  goals — presume  that  one  knows  currently  how 
productive  a  project  or  organizations  is,  how  many  defects  are  currently  delivered,  and  what  the  cycle 
time  currently  is,  respectively.  Even  “Achieve  CMMI  Maturity  Level  2  by  date  X”  (a  process 
capability  goal)  implies  that,  if  measured  by  a  SCAMPI  A,  an  organization  is  currently  at  ML  1. 

As  implied  above,  both  project  perfonnance  and  process  capability  are  valid  targets  for  improvement. 
AIM  takes  the  view  that  these  are  not  just  compatible  but  complementary,  at  least  when  performance 
is  pursued  using  the  known-capable  methods  recommended  in  this  report.  How  well  the  organization 
and  typical  projects  perform  currently  should  inform  any  such  goals  and  also  act  as  a  starting  point  for 
realistic  improvement  efforts.  While  many  software-intensive  organizations  cannot  put  a  number  on 
productivity  or  delivered  defects  or  cycle  times,  that  does  not  imply  that  such  numbers  do  not  exist;  it 
may  mean  simply  that  they  need  to  be  retrieved  from  their  current  hiding  places. 

It  may  be  that  performance  and  capability  can  be  assumed  at  the  start  and  validated  as  the  effort 
progresses.  For  example,  it  was  a  significant  advance  for  the  CMMI  community  to  recognize  that 
there  is  little  value  in  doing  a  full  SCAMPI  A  in  an  organization  that  is  clearly  at  maturity  level  1 , 
especially  when  the  same  starting-point  information  could  be  gathered  with  a  less  formal,  and  less 
costly,  SCAMPI  B.  When  doing  SCAMPIs  as  part  of  an  AIM  effort,  it  often  makes  sense  to  delay 
even  the  fonnality  of  a  SCAMPI  B  until  sometime  after  pilot  projects  have  started,  and  then  to  include 
in  the  appraisal,  projects  both  inside  and  outside  the  current  scope  of  AIM.  This  contrast  provides 
clear  context  for  the  organization’s  pre-AIM  capabilities. 

Characterizing  performance  can  be  more  difficult.  Postmortems  that  gather  and  begin  to  summarize 
and  analyze  individual  project  performance  are  a  standard  feature  of  AIM  projects,  but  knowing  or 
even  making  an  intelligent  guess  as  to  where  the  organization  was  prior  to  the  AIM  effort  can  be 
challenging.  Perhaps  the  development  part  of  the  organization  doesn’t  have  its  productivity  or 
delivered  defect  numbers,  but  the  testing  part  of  the  organization  is  likely  to  have  some  relevant 
information  from  which  one  might  be  able  to  derive  a  useful  performance  baseline,  however  narrow 
that  might  be.  Basic  accounting  infonnation  such  as  timecards  and  actual  budget  and  schedule  results 
can  be  used  to  estimate,  for  example,  the  percentage  of  time  and  effort  typically  spent  in  formal  testing 
compared  to  the  overall  project.  Even  qualitative  instruments  such  as  surveys  can  be  used,  especially 
before  and  after  pilot  projects,  to  help  assess  performance  improvements  from  the  adoption  of  AIM 
techniques. 

If  an  organization  desires  or  requires  CMMI  validation  recognized  by  the  wider  world,  SCAMPI  A  is 
the  only  official  method.  As  stated  previously,  the  AIM  target  is  CMMI  maturity  level  3,  but  the 
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implementing  organization  must  understand  the  implications  of  preparing  for  and  successfully 
executing  a  SCAMPI  A,  as  well  as  the  limitations  of  AIM  “out  of  the  box.”  The  most  apparent  path  to 
this  is  a  series  of  SCAMPI  B  and  C  activities,  both  formal  and  informal,  and  of  varying  scope,  tailored 
to  assessing  how  well  the  organization  has  implemented  AIM  with  respect  to  CMMI,  including  a 
search  for  problems  with  current  practices  and  opportunities  for  improvement. 

SCAMPI  A  requires  an  SEI-certified  SCAMPI  Lead  Appraiser  (LA),  and  the  selection  of  the  LA  is  an 
important  step  in  this  process,  regardless  of  whether  the  organization  is  using  AIM  or  some  other 
approach  to  implementing  CMMI -compatible  practices.  The  LA  and  the  organization  should  be  on  the 
same  page  from  the  beginning,  including  letting  the  LA  know  up  front  how  the  organization  is 
approaching  CMMI  implementation.  The  LA  may  or  may  not  lead  the  SCAMPI  B/C  activities, 
depending  on  a  host  of  factors  including  cost  and  scheduling,  but  the  data  gathered  and  the  lessons 
learned  in  these  activities  usually  inform  and  guide  SCAMPI  A  preparations.  The  Guide  for  SCAMPI 
Appraisals:  Accelerated  Improvement  Method  (AIM)  [Miluk  20 1 0]  provides  CMMI-referenced 
information  on  “standard”  AIM  practices  that  should  prove  useful  to  Lead  Appraisers,  appraisal  team 
members,  PG  members,  and  other  personnel  involved  in  the  effort. 

2.3  Identifying,  Training,  and  Launching  Pilot  Projects 

The  execution  thread  of  identifying,  training,  and  launching  pilots  is  perhaps  the  best  understood 
thread,  in  that  it  has  been  used  for  over  a  decade  for  TSP  introduction,  and  has  extensive  description 
elsewhere  [Humphrey  2011].  The  key  challenge  is  identifying  pilot  projects  that  are  both  likely  to 
succeed  and  also  likely  to  be  seen  as  valid  examples  for  the  rest  of  the  organization  to  follow.  The 
number,  kind,  and  scope  of  pilot  projects  varies  according  to  the  organization’s  size  in  terms  of  project 
mix,  the  range  of  project  sizes  and  types,  typical  durations,  and  type  and  numbers  of  development 
staff. 

Once  pilot  projects  have  been  identified,  they  can  proceed  rapidly.  Training  for  the  various  roles 
involved  in  development  projects  is  well-defined  and  can  be  taught  in  parallel,  although  there  is  a 
preference  to  deliver  Leading  a  Development  Team  first  to  make  managers  and  team  leaders  aware  of 
the  training  that  their  personnel  will  soon  receive. 


Table  1:  Role-Based  Training 


Course 

Target  Audience 

Duration 

Leading  a  Development  Team4 

Team  leaders,  line  managers 

3  days 

PSP  Fundamentals*5 

Software  developers 

5  days 

TSP  Team  Member  Training6 7 

All  other  development  team  personnel 

3  days 

*PSP  Advanced 7  is  highly  recommended  for  software  developers  once  they  have  had  some  experience 
applying  the  skills  and  principles  taught  in  PSP  Fundamentals. 


Project  teams  should  be  trained  together  whenever  possible,  and  project  launches  should  follow 
closely  after  the  training.  One  should  note  that  preparation  and  the  actual  launch  events  typically 
involve  managers  above  the  first  level,  often  up  to  the  senior  executive  level,  who  explain  the 


4  Leading  a  Development  Team,  http://www.sei.cmu.edu/traininq/p17b.cfm. 

5  Personal  Software  Process  (PSP)  Fundamentals,  http://www.sei.cmu.edu/traininq/p18b.cfm. 

6  TSP  Team  Member  Training,  http://www.sei.cmu.edu/traininq/p16b.cfm. 

7  Personal  Software  Process  (PSP)  Advanced,  http://www.sei.cmu.edu/traininq/p19b.cfm. 
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organization’s  goals  and  reasons  for  AIM  implementation  as  well  the  goals  and  particulars  of  each 
project  being  launched.  This  is  an  intended  overlap  with  the  Executive  Sponsorship  thread  and  the 
Training  and  Launching  threads.  Regular  reviews  with  sponsoring  management  must  also  become  a 
regular  AIM  feature  (and  part  of  the  Continuous  Improvement  thread),  at  least  quarterly,  although 
monthly  is  common  and  bi-weekly  or  even  weekly  reviews,  especially  during  pilot  projects  have 
occurred. 

The  process  scripts  TOPS  and  TOPS 7  in  Appendix  B  provide  the  best  summary  of  activities 
surrounding  the  preparation,  launch,  and  execution  of  AIM  development  teams. 

2.4  Identifying,  Training,  and  Launching  the  PG 

Organizations  pursuing  CMMI-based  improvements  are  often  admonished  to  “treat  process 
improvement  like  a  project,”  but  concrete  guidance  on  exactly  how  to  do  this  does  not  often  follow. 
AIM  requires  that  the  PG  is  trained  and  launched  exactly  like  every  other  team,  although  with  very 
different  goals  and  requirements  compared  to  most  projects.  As  the  organization’s  experience  with 
accumulated  data  from  AIM  projects  grows,  the  PG  will  require  additional  training,  in  Six  Sigma 
methods,  in  order  to  analyze,  characterize,  and  act  upon  the  large  amounts  of  data  that  AIM  projects 
produce. 

The  minimum  initial  training  for  the  PG  is  Introduction  to  CMMI-DEV  and  either  PSP  Fundamentals 
or  TSP  Team  Member  Training.  Highly  recommended  is  Implementing  Goal-Driven  Measurement. 
Depending  on  the  size  and  needs  of  the  organization  and  the  preferences  of  individual  members,  some 
members  of  the  PG  may  further  develop  their  CMMI  expertise.  Some  may  choose  additional 
coursework  leading  to  becoming  certified  to  teach  the  Introduction  to  CMMf  class  or  even  become  a 
SCAMPI  Leader  Appraiser  or  SCAMPI  B/C  Team  Leader,  while  others  may  choose  to  follow  the 
path  to  become  PSP  Instructors  or  TSP  Coaches. 

Planning  and  developing  for  the  scope,  implementation,  and  internal  capabilities  of  the  target 
organization  to  deliver  training  and  coaching  services  is  a  paramount  responsibility  of  the  PG  under 
AIM,  and  maps  directly  to  the  strategic  training  needs  under  the  CMMI  process  area  Organizational 
Training  (OT),  as  well  as  tactical  needs  identified  by  projects  (see  PP  SP  2.5  and  GP  2.5  for  relevant 
PAs).  Typical  initial  PG  goals  include  addressing  the  organization’s  strategic  training  needs,  including 
AIM-related  skills.  Having  some  level  of  internal  TSP  coaching  capability,  for  example,  is  a  hallmark 
of  success  for  most  organizations,  so  either  hiring  or  identifying  and  developing  internal  coaches  is  a 
critical  activity.  Internal  resources  also  help  to  speed  the  rate  of  implementation  through  the 
organization. 

Another  major  PG  responsibility  is  the  establishment  and  maintenance  of  organizational  process  assets 
as  described  in  the  CMMI  process  area  Organizational  Process  Definition  (OPD).  Obviously,  the  AIM 
process  assets  become  part  of  this  definition;  however,  even  the  most  chaotic  of  organizations 
typically  have  some  core  processes  that  can  rightly  be  identified  as  good  practices  that  should  be 
preserved  and  built  upon.  In  fact,  the  AIM  approach  to  the  Engineering  process  category  (see  below  in 
Section  3.11)  specifies  that  the  organization’s  existing  development  practices  are  treated  as  the 
starting  point  in  those  areas.  The  initial  pilot  projects  in  any  organization  will  typically  identify  and 
perhaps  formalize  these  practices,  which  should  in  turn  simplify  the  PG’s  task  of  caphiring  these 
practices  and  related  execution  data  for  use  by  other  projects. 


Introduction  to  CMMI  for  Development  vl.3,  http://www.sei.cmu.edu/traininq/p91.cfm. 
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The  final  major  responsibility  for  the  PG  relates  to  the  CMMI  process  area  Organizational  Process 
Focus  (OPF),  which  deals  with  identifying  strengths,  weaknesses,  and  improvement  opportunities  for 
the  organization’s  process  capabilities,  planning  and  implementing  process  improvements,  and 
deploying  process  assets  across  the  organization,  while  incorporating  the  lessons  learned  by  the 
projects.  In  essence,  this  puts  the  PG  in  the  position  of  coordinating  all  of  the  threads  of  AIM 
execution  on  an  ongoing  basis.  A  general  description  of  PG  startup  and  ongoing  execution  can  be 
found  in  process  scripts  POPS  and  POPS7  in  Appendix  B. 

2.5  Evaluating  Pilot  Projects  and  Planning  Further  Rollout 

Certainly  after  the  presumed  successful  use  of  AIM  methods  on  pilot  projects,  and  sometimes  even 
earlier  (especially  on  larger  projects),  an  organization  may  decide  to  adopt  AIM  across  the 
organization,  or  to  proceed  to  a  second  round  of  pilot  projects  reflecting  a  broader  range  of  projects  in 
the  organization.  In  the  smallest  organizations,  broad  adoption  may  be  an  accomplished  fact  because 
the  entire  organization  has  already  been  trained  and  is  using  the  methods,  or  it  may  simply  be  a  matter 
of  training  the  rest  of  the  personnel  and  launching  one  or  two  more  teams.  Larger  organizations  have 
the  problems  of  training  and  sequencing  ongoing  training  requirements,  plus  when  and  how  to  launch 
TSP  techniques  with  remaining  teams.  And  all  organizations  have  the  ongoing  issue  of  providing  the 
skilled  TSP  and  CMMI  expertise  necessary  to  maintain  AIM  implementation,  and  eventually  broaden 
the  scope  of  data  analysis,  possibly  with  Six  Sigma  techniques. 

All  AIM  projects,  and  even  cycles  within  those  projects  as  depicted  in  Figure  3,  end  with  postmortem 
(PM)  events.  These  postmortem  events  characterize  project  performance  for  use  by  the  team  doing  the 
next  cycle  or  project,  and  which  feed  into  the  organization’s  long-term  memory  for  use  by  future 
teams  and  possibly  by  the  PG  or  other  group  for  further  analysis.  A  general  description  of  a  TSP  cycle 
can  be  found  in  process  script  CYCLE  in  Appendix  B.  While  fulfilling  particular  CMMI  practices 
(notably  GP  3.2  for  many  PAs),  an  important  part  of  the  PM  is  gathering  PIPs  (Process  Improvement 
Proposals)  that  reflect  problems  and  observations  made  by  development  teams  in  the  course  of  doing 
their  work.  These  can  range  from  complaints  on  defect  tracking  that  can  lead  to  a  simple  standard  for 
using  an  existing  field  in  an  existing  tool,  to  a  suggestion  to  develop  an  entire  new  process  discipline 
such  as  formal  architecture  methods  in  order  to  avoid  entire  sets  of  problems  encountered  by  large- 
scoped  projects. 
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Figure  3:  The  TSP  Development  Cycle  Structure 

Planning  and  executing  a  broad  rollout  of  AIM  methods,  especially  in  a  larger  organization,  can  fall 
either  to  the  existing  PG  or  to  a  related  team  of  outside  resources  that  have  the  capacity,  for  example, 
to  train  a  large  number  of  personnel  quickly  and  then  to  launch  those  people  as  TSP  teams,  using 
process  assets  that  may  or  may  not  have  been  updated  by  pilot  project  teams.  Even  in  the  case  of 
outside  resources,  the  PG  should  be  involved  with  every  step  of  the  process,  if  only  because  they  will 
have  to  live  with  the  results.  The  PG  can  also  warn  of  potential  pitfalls  that  only  organization  insiders 
would  recognize,  and  help  to  navigate  around  them.  In  the  best  case,  the  PG  will  be  heavily  involved 
in  training  and  launching  new  teams,  especially  in  preparing  and  advising  them  on  the  use  of  the 
organization’s  standard  process  assets. 

2.6  Building  a  Culture  of  Excellence  and  Continuous  Improvement 

Ideally,  there  comes  a  time  when  the  entire  existing  organization  has  been  trained,  mechanisms  have 
been  implemented  to  train  new  developers  and  managers,  projects  new  and  old  contribute  to  the 
organization’s  process  assets,  the  organization  has  been  officially  appraised  at  CMMI  ML3,  and 
management  talks  the  talk  and  walks  the  walk.  While  this  is  a  significant  achievement,  AIM  can  and 
should  be  used  to  do  more.  If  an  organization  says  “we’re  good  enough”  then,  in  some  sense,  a 
business  opportunity  may  be  passed  up,  and  a  potentially  significant  risk  may  be  forming. 

The  business  opportunity  is  in  the  potential  of  the  organization  to  go  far  beyond  its  previous 
performance,  based  on  detailed  quantitative  knowledge  of  its  own  capabilities.  This  could  mean  using 
Six  Sigma  methods  to  achieve  a  high  CMMI  maturity  level,  or  it  could  mean  simply  using  those 
methods  to  focus  narrowly  on  the  aspects  of  project  execution  that  matter  most  to  the  business.  Is 
there  opportunity  to  “lean”  the  process  to  achieve  significantly  faster  throughput,  and  therefore, 
significantly  higher  productivity?  Is  there  an  opportunity  to  reduce  industry-best  defect  densities  to 


CMU/SEI-201 0-SR-032  |  15 


levels  that  are  truly  world-class,  and  thereby  differentiate  a  product  in  an  extraordinary  way?  Only  an 
organization  with  hard  data  that  relates  their  processes  to  their  performances  can  answer  these 
questions  adequately,  and  then  execute  based  on  the  answers. 

On  the  opposite  side  of  the  business  opportunity  is  the  risk.  If  an  organization  decides  not  to  pursue 
improvement  and  wants  current  performance  “merely”  to  be  sustained,  what  signal  does  that  send  to 
employees  and  customers  alike?  In  a  dynamic  and  competitive  world,  is  it  even  possible  to  maintain 
perfonnance  when  new  competitors,  new  technologies,  and  new  circumstances  constantly  redefine 
where  the  bright  line  of  excellence  is  drawn?  The  AIM  philosophy  is  that  continuous  improvement  is 
not  an  option,  because  the  world  in  which  we  live  moves  so  quickly  that  one  must  move  quickly  ahead 
or  be  left  behind. 

Building  a  culture  of  excellence  is  the  most  difficult  and  also  the  most  important  long-term  execution 
thread  in  AIM.  Consider  what  can  happen  in  its  absence:  A  key  executive  leaves,  the  replacement 
focuses  on  short-term  gains,  a  middle  manager  nearing  retirement  decides  to  go  with  the  flow,  a  team 
leader  loses  focus  because  her  boss  doesn’t  seem  to  care,  her  team  loses  focus  because  its  leader  is 
distracted.  If  people  revert  to  even  some  of  their  former  behaviors,  much  of  the  performance 
improvement  and  business  benefits  of  implementing  AIM  can  be  quickly  lost.  It  is  the  job  of  all 
parties — sponsoring  executives,  middle  and  line  managers,  team  leaders,  the  PG,  the  developers — not 
just  to  do  their  jobs,  but  also  to  demand  excellence  of  themselves  and  their  co-workers.  This  job 
demands,  in  turn,  not  just  executing  the  existing  AIM  methods,  but  adapting  and  improving  the 
methods  for  better  performance  on  the  next  project  as  compared  to  the  current  one.  CMMI  can  provide 
a  framework,  TSP  can  provide  implementation  excellence,  SCAMPI  can  verify  compliance,  Six 
Sigma  methods  can  help  with  analysis  of  the  data  and  the  formulation  of  new  goals  and  process 
changes  to  achieve  them — but  the  motivation  to  use  these  methods  to  find  new  potential 
improvements  in  cycle  time  or  delivered  defects  or  project  predictability  beyond  what  was  achieved 
just  last  year  comes  from  the  people  using  the  methods. 
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3  Specific  Guidance  for  AIM  Implementers 


This  section  provides  specific  information  for  those  charged  with  implementing  AIM  practices.  Like 
the  blind  men  describing  the  various  parts  of  an  elephant,  in  some  cases  there  is  a  strong  conceptual 
thread  that  is  obviously  carried  from  one  topic  to  another,  while  in  others  the  only  common  thread  is 
that  the  description  is  of  another  aspect  of  AIM.  The  following  topics  need  not  be  implemented  or 
even  read  in  the  given  order;  however,  the  authors  recommend  reading  them  all  through  once  and  then 
taking  action  on  the  ones  that  apply,  considering  specific  information  from  the  appendices,  and  from 
other  relevant  sources.  This  is  generally  the  work  of  the  PG  in  any  organization,  possibly  with  the  use 
of  expert  resources  from  within  or  outside  of  the  organization. 

The  Guide  for  SCAMPI  Appraisals:  Accelerated  Improvement  Method  (AIM)  [Miluk2010]  is  a 
necessary  companion  document.  AIM  exists  because  of  the  many  documented  instances  of  TSP  being 
used  to  implement  CMMI  (and  previously,  SW-CMM)  practices,  most  often  in  concert  with  other 
“known  good”  practices  like  Six  Sigma  or  Goal  Driven  Measurement  or  locally  grown  procedures 
[McHale  2004,  Saint- Armand  2007,  Seshagiri  2009].  The  basic  combination  of  a  proven  starting  point 
of  operational  practices  and  a  deliberately  general  set  of  best-practice  descriptions  allows  broad 
choices  for  implementers.  Having  the  clear,  documented  links  between  the  two  provides  both  an 
introduction  to  the  main  implementation  vehicle  in  CMMI  terms,  and  a  “worked  example”  of  high- 
performance  CMMI  practices  and  artifacts. 

3.1  Certified  Experts — A  Caveat  and  Disclaimer 

It  is  important  to  work  with  certified  experts  in  PSP,  TSP,  CMMI  and  SCAMPI,  and  Six  Sigma  when 
implementing  AIM.  While  the  ultimate  goal  of  AIM  is  for  an  organization  to  achieve  self-sufficiency, 
every  success  story  that  the  authors  can  point  to  involves  the  proper  training,  coaching,  consulting, 
and  other  expertise  in  preparing,  coaching,  executing,  and  evaluating  the  recommended  practices  that 
make  up  AIM.  In  other  words,  while  there  are  known  cases  where  the  path  to  expertise  and  excellence 
has  been  shortened,  there  are  no  examples  where  the  path  can  be  short-cut.  Many  of  the  failures  lack 
one  or  more  of  these  apparently  critical  requirements  for  success,  and  all  of  them  rely  on  the  use  of 
qualified  experts. 

Perhaps,  as  time  passes,  a  target  organization  will  customize  and  adapt  AIM  practices  until  they  are 
almost  unrecognizable  as  what  began  as  something  called  “AIM,”  and  the  organization’s  own  people 
will  become  the  experts.  However,  that  progression  seems  somewhat  risky,  if  not  downright  unlikely, 
if  the  starting  point  is  very  far  from  the  basics  of  the  component  technologies.  The  path  described  in 
this  report  involves  both  a  known  start  and  a  known  end.  One  of  the  basic  tenets  of  TSP  applies  here, 
namely,  that  the  fastest  and  cheapest  way  to  implement  is  usually  to  do  it  right  in  the  first  place. 

3.2  Three  Use  Cases 

AIM  identifies  three  common  use  cases  for  combining  CMMI  and  TSP  technologies. 

1 .  CMMI  has  some  significant  implementation  in  the  organization,  and  TSP  is  being  introduced. 

2.  TSP  has  some  significant  implementation  in  the  organization,  and  CMMI  is  being  introduced 
more  explicitly. 
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3.  The  organization  has  no  significant  implementation  of  or  experience  with  either  CMMI  or  TSP, 
and  therefore,  both  must  be  introduced. 

The  expectation  is  that  it  should  be  obvious  to  any  organization  that  decides  to  use  AIM  which  use 
case  (UC)  applies  in  the  current  instance.  AIM  is  designed  generally  for  the  third  use  case,  an 
organization  without  CMMI  or  TSP  experience,  with  the  first  two  UCs  having  already  implemented 
perhaps  the  only  workable  “shortcut”  to  the  desired  end. 

Each  use  case  presents  its  own  unique  profile  of  problems  and  opportunities,  and  in  fact  the  three 
mentioned  above  represent  an  entire  class  of  usages  across  a  spectrum.  For  example,  the  CMMI-extant 
organization  (UC1)  can  be  at  any  CMMI  maturity  level,  ML1  to  ML5,  and  the  precise  details  of  the 
existing  practices  strongly  influence  how  TSP  introduction  and  adaptation  should  proceed.  TSP-extant 
organizations  (UC2)  may  have  implemented  such  discipline  across  all  development  projects  or  just  a 
few  projects,  and  may  or  may  not  have  their  own  TSP  coaches  on  staff.  Even  UC3  organizations  that 
have  no  formal  CMMI  or  TSP  programs  in  place  may  possess  other  existing  good  practices  like  Six 
Sigma  or  Scrum,  and  even  home-grown  methods  must  be  recognized  and  incorporated  into  the  new 
AIM  practices.  For  all  use  cases,  regardless  of  experience  with  CMMI  and  TSP,  the  size  and  culture  of 
the  organization,  and  the  average  and  extreme  project  durations  must  also  be  accommodated  during 
implementation.  These  are  just  a  few  of  many  relevant  factors, 

One  important  activity  under  any  use  case  based  on  an  existing  implementation  of  either  TSP  or 
CMMI  is  the  verification  of  existing  practices.  One  may  assume  from  conversation  and  observation 
that,  for  example,  an  organization  has  significant  experience  and  expertise  in  TSP.  However,  the 
quality  of  the  TSP  implementation,  which  can  only  be  known  by  a  detailed  assessment  of  that 
implementation,  can  make  huge  differences  in  the  necessary  course  of  action  going  forward.  If  TSP 
implementation  is  in  some  way  superficial  or  incomplete,  or  simply  dates  to  a  much  earlier  version  of 
TSP  than  the  current  one,  planning  and  execution  of  AIM  may  be  best  served  by  first  “upgrading”  to 
the  current  version,  with  particular  emphasis  on  any  uncovered  shortcomings  in  the  prior 
implementation. 

3.3  Which  Version  of  TSP  Supports  AIM? 

TSP  has  been  extended  formally  for  AIM  as  a  result  of  a  formal  gap  analysis,  in  the  mode  of  a 
SCAMPI  C  analysis,  which  was  conducted  at  the  SEI  in  2008-2009.  As  a  result  of  that  analysis,  a 
series  of  Process  Improvement  Proposals  (PIPs)  were  generated  to  address  specific  gaps  or  groups  of 
gaps.  For  example,  the  lack  of  policy  statements  in  TSP  resulted  in  a  gap  for  GP  2.1  of  every  PA  in 
the  scope  of  the  analysis.  The  original  observations  noting  these  gaps,  as  well  as  revised  observations 
that  point  to  the  present  document  (for  example,  for  policy  guidance),  are  recorded  in  the  Guide  for 
SCAMPI  Appraisals:  Accelerated  Improvement  Method  (AIM)  [Miluk  2010].  A  copy  of  the  original 
PIPs  are  available  in  Appendix  D. 

The  PIPs  were  written  in  many  cases  referencing  the  basic  process  elements  that  make  up  TSP: 
scripts  that  describe  processes  at  an  expert  level,  checklists  that  guide  critical  procedures  or  capture 
critical  information  or  both,  forms  that  capture  process  data,  giddelines  that  provide  additional 
information  on  specific  topics,  and  specifications  that  describe  things  like  reports,  documents,  or  roles. 
TSP  also  calls  for  the  creation  of  local  standards  such  as  a  coding  or  design  standard,  defect 
classification  standard,  or  documentation  standard  that  are,  in  some  sense,  another  kind  of 
specification.  Another  process  element  is  the  tool  set  one  uses  to  implement  one  or  more  aspects  of  the 
process,  preferably  in  an  automated,  integrated  way;  however,  such  automation  usually  enhances  or 
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takes  the  place  of  some  step  or  steps  in  a  script,  or  captures  data  specified  for  a  given  form  or 
according  to  a  given  standard.  A  list  of  the  TSP  process  assets  that  were  the  target  of  the  gap  analysis 
is  available  in  the  Guide  for  SCAMPI  Appraisals:  Accelerated  Improvement  Method  (AIM)  [Miluk 
2010], 

The  new  version  of  TSP  that  resulted  from  these  observations  and  PIPs  is  popularly  called  “TSP+,” 
with  the  official  designation  “TSP+  2010.09.”  This  version  is  available  only  to  SEI  Partners  for  TSP. 
The  popular  naming  derives  from  the  idea  that  this  version  is  everything  that  was  present  in  both 
released  and  unreleased  versions  (such  as  TSPm  which  can  be  used  to  address  the  IPPD  aspects  of  the 
CMMI)  of  TSP  previously,  plus  the  added  and  modified  process  elements  necessary  to  address  certain 
practices  or  groups  of  practices  in  the  CMMI.  In  several  cases  where  an  existing  process  element  was 
modified  in  accordance  with  CMMI  guidance,  the  change  that  resulted  also  had  the  effect  of 
addressing  a  known  problem  or  issue  with  TSP  implementation. 

3.4  Implementation  Approach 

The  general  approach  to  implementing  any  AIM  practice  is  to  first  recognize  that  there  may  be 
existing  practices  within  the  organization  that  are  perfectly  adequate  as  they  stand,  or  that  may  be 
partially  workable  in  conjunction  with  AIM  practices.  A  primary  purpose  of  the  pilot  projects  is  to 
highlight  such  existing  practices  and  then  to  determine  how  to  integrate  AIM  practices  effectively 
with  them.  Furthermore,  it  is  not  primarily  the  AIM  experts  who  make  such  determinations;  rather,  it 
is  the  pilot  teams  themselves,  including  the  PG,  guided  by  the  experts,  who  make  such  determinations. 

The  bias  in  AIM  implementation  is  that  the  working  processes  belong  to  the  team,  therefore  the  team 
must  decide  what  existing  practices  should  be  used  within  the  AIM  framework  for  the  management, 
measurement,  and  execution  of  their  work.  Such  practices  may  be  used  as  they  are,  may  require 
modification  for  use  within  AIM,  or  may  actually  be  replaced  by  a  relevant  AIM  practice.  If  a  practice 
is,  in  fact,  not  measuring  up,  the  AIM  measurement  framework  usually  demonstrates  that  fact  in  a 
literal  sense.  For  example,  if  an  inspection  process  exists  and  the  team  wishes  to  continue  to  use  it 
instead  of  the  TSP  inspection  process,  the  team  plans  and  tracks  such  inspections  just  like  any  other 
piece  of  work.  However,  if  that  inspection  process  doesn’t  work  very  well  in  terms  of  defect  yield  or 
defects  found  per  unit  time  or  some  other  relevant  measure  of  effectiveness,  the  team  will  have 
objective  data  that  not  only  justifies  a  change,  but  demands  one. 

Very  often,  a  new  AIM  practice  must  learn  to  co-exist  with  existing  practices.  A  fairly  common 
example  is  that  of  existing  project  management  practices.  A  medium-to-large-sized  organization  often 
sets  up  some  kind  of  project  management  office  (PMO)  to  ensure  that  adequate,  consistent  planning 
and  tracking  efforts  are  applied  to  every  project.  AIM  teams  create  and  update  their  plans  using  the 
TSP  launch/relaunch  processes,  and  track  progress  at  the  weekly  team  meetings.  Someone,  usually  the 
planning  manager  or  team  leader,  must  then  provide  the  right  information  in  the  right  format  in  the 
right  timeframe  to  the  PMO  [Chick  2006].  This  is  usually  a  matter  of  selecting  the  proper  subset  of 
existing  data  needed  by  the  PMO,  since  AIM  teams  typically  generate  far  more  detailed  data  than  the 
typical  PMO  requires. 

Many  of  the  remaining  topics  in  this  section  cover  CMMI  PAs  that  should  be  approached  in  just  this 
way:  look  for  overlaps  and  potential  conflicts  between  existing  organizational  practices  and  AIM 
practices,  and  use  pilot  project  experience  and  expertise  to  determine  how  these  practices  will  adapt 
and  co-exist  going  forward.  Even  after  full  implementation  of  AIM  methods  is  achieved,  this  is  a  good 
approach  to  take  when  implementing  process  changes.  Attempting  across-the-board  implementation  of 
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new  practices  in  all  but  the  smallest  (one-  and  two-team)  organizations  does  not  usually  end  well. 
Major  changes  to  a  project  team’s  process  should  be  made  during  the  project  team’s  launch  or 
relaunch  as  part  of  their  project  execution  cycle  (see  script  CYCLE  in  Appendix  B).  Forcing 
organizational  process  changes  in  mid-cycle  can  be  extremely  disruptive  to  a  project’s  productivity. 

By  introducing  such  changes  during  a  team’s  natural  planning  phase,  the  team  is  able  to  account  for 
and  anticipate  the  process  changes  into  their  negotiated  commitments  made  with  management  and 
other  relevant  stakeholders. 

3.5  Measurement  and  Analysis 

On  the  surface,  there  should  be  few  issues  surrounding  implementation  of  the  Measurement  and 
Analysis  (MA)  PA  in  CMMI  in  an  AIM-based  effort.  Measurement  is  a  hallmark  of  the  TSP.  Direct 
process  measurements  at  the  most  fundamental  level — the  individual  developer — are  introduced  and 
trained  intensively  in  the  PSP  and  demanded  daily  on  a  task-by-task  basis  of  TSP  team  members,  and 
certain  fundamental  analysis  of  this  data  occurs  weekly  on  every  TSP  project.  Few  existing 
organizations  have  even  attempted  measurements  at  this  detailed  level.  Despite  this  the  coverage  was 
not  perfect  initially  for  the  CMMI-specific  practices  (SPs)  of  this  PA,  due  largely  to  the  lack  of 
explicitly  documented  measurement  objectives,  the  subject  of  MA  SP  1.1.  (See  PIP  MA-1  in 
Appendix  D.) 

Fortunately,  there  are  at  least  two  non-exclusive  methods  available  to  deal  with  this  issue.  First,  Goal 
Driven  Measurement  training  provides  a  template  that  captures  the  information  needed  for  the  Goal- 
Question-Indicator-Metric,  or  GQ(I)M,  paradigm  [Park  1996],  In  fact,  the  indictor  templates  capture 
much  more  data  than  is  actually  needed  for  the  narrow  purpose  of  meeting  MA  SP  1 . 1 ,  as  explained  in 
Applications  of  the  Indicator  Template  for  Measurement  and  Analysis  [Goethert  2004].  The  additional 
information  also  provides  an  organizational  guide  for  many  activities  of  the  PG  with  respect  to  the 
measurement  repository  (OPD  SP  1.4)  and  the  many  related  specific  and  generic  practices,  especially 
planning  for  and  monitoring  project  data  (PP  SP  1.3  and  PMC  SP  1.4),  and  using  and  contributing  to 
organizational  process  assets  (IPM  SPs  1.2  and  1.6  and  the  corresponding  GPs  3.1  and  3.2,  for  any 
activities  planned  and  tracked  by  TSP  teams). 

A  second,  more  narrowly  focused  method,  used  with  good  results  on  an  AIM  pilot  project  [Fleshman 
2010],  is  to  address  the  issue  of  measurement  objectives  in  a  policy  statement.  This  method  has  the 
advantage  of  making  such  a  policy  specific  and  actionable,  while  also  addressing  MA  GP  1 . 1 .  As 
implied  above,  the  two  methods  can  co-exist  on  any  given  implementation.  This  is  one  of  the  many 
choices  for  implementation  to  be  made  in  AIM,  usually  by  the  PG. 

Finally,  the  basic  TSP  data  and  project-level  analysis  should  be  the  starting  point  for  MA  in  an 
organization,  not  the  end  point.  The  indicator  templates  provide  a  known  path  to  a  wider  world  of 
effective  organizational  use  of  measurement.  This  becomes  more  explicit  for  higher  levels  of  CMMI 
maturity  (outside  of  the  current  scope  of  AIM),  however  almost  any  thoughtful  application  of  Six 
Sigma  methods  creates  actions  and  artifacts  that  will  show  well  during  a  SCAMPI  appraisal  and,  more 
importantly,  provide  value  to  the  organization. 

In  a  broader  sense,  the  way  in  which  AIM  addresses  MA  is  indicative  of  the  general  AIM  philosophy 
and  implementation  strategy.  The  core  of  the  implementation,  proven  in  the  field  for  over  a  decade, 
begins  with  PSP  training  and  TSP  implementation.  The  SCAMPI  C  observations  in  the  Guide  for 
SCAMPI  Appraisals :  Accelerated  Improvement  Method  (AIM)  [Miluk2010]  shows  a  potential 
shortcoming,  and  a  solution  is  provided  (i.e.,  a  gap  is  filled  for  MA  SP  1.1)  based  on  the  existing 
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practices,  or  in  this  instance,  by  GQ(I)M.  By  using  CMMI  specific  and  generic  practices  and  the 
accompanying  observations  as  a  guide,  an  alternative  and  perfectly  valid  solution  is  formulated  to 
address  not  just  this  particular  gap,  but  also  the  MA  GP  1.1  gap  as  well.  The  SCAMPI  appraisal  that 
verifies  a  particular  method  or  methods  as  compliant  with  the  model  does  not  distinguish  between 
AIM  and  locally  developed  methods. 

3.6  Organizational  Policy 

The  subject  of  organizational  policy  arises  throughout  AIM  implementation,  not  only  because  there  is 
a  generic  practice  for  policy  (GP  1.1.)  applicable  to  every  PA  in  the  CMMI,  but  also  for  the  links  to 
management’s  intentions  for  usage  of  the  AIM  process  assets  and  the  data  that  usage  of  these  methods 
creates.  The  general  AIM  recommendation  is  that  the  policies  related  to  AIM  reflect  the  stages  of  AIM 
introduction  and  an  evolving  understanding  of  how  AIM  practices  are  being  used  in  the  organization. 
Therefore,  policy  statements  must  be  revisited  with  reasonable  frequency,  probably  every  six  months 
or  so,  during  the  first  few  years  of  AIM  usage. 

For  example,  an  initial  policy  could  be  in  the  form  of  a  memo  from  the  executive  sponsor,  stating  an 
intention  to  pilot  AIM  usage  within  the  organization,  the  overall  goals  for  AIM  implementation,  and 
naming  a  responsible  manager  and/or  group.  Six  months  later,  related  individual  policy  statements 
might  be  issued:  when  pilot  projects  are  well  underway  or  finishing,  when  the  PG  is  readying  to 
launch,  and  the  organization  understands  how  to  integrate  AIM  practices  with  existing  project 
management  practices,  quality  assurance  practices,  and  parts  of  an  engineering  life  cycle.  This 
experience  will  be  reflected  in  a  more  sophisticated  set  of  policies.  In  another  six  months,  after  one  or 
two  cycles  of  PG  efforts  and  a  broadened  set  of  development  projects  under  the  revised  policies,  the 
PG  would  draft  a  small  but  comprehensive  set  of  five  to  ten  new  policies  that  matched  the 
organization’s  goals  with  the  project  management,  process  management,  engineering  management, 
and  the  various  support  activities  that  represented  the  new  standard  of  expected  behavior. 

Organizational  policy  under  AIM  should  evolve  as  organizational  practice  evolves,  and  the 
organization  is  best  served  if  it  develops  and  adapts  such  policy  internally.  AIM  therefore  offers  no 
generic  policy  statements.  Rather,  as  the  organization  pilots,  uses,  and  adapts  AIM  methods,  it  shapes 
policy  statements  to  direct  the  expected  “new  normal”  behaviors. 

3.7  Process  Group  Strategy  and  Coaching 

In  an  early  step  in  the  TSP  launch  process  that  AIM  teams  use  to  plan  their  work,  the  team  in  question 
must  decide  upon  an  overall  strategy  for  their  work.  While  there  are  many  available  options  and  many 
decisions  to  be  made,  the  AIM  framework  requires  an  initial  strategy  that  is  compatible  with  the 
CMMI  model,  the  SCAMPI  appraisal  method,  and  the  TSP  operational  practices. 

The  two  most  obvious  implementation  strategies,  built  into  CMMI  itself,  reflect  the  staged  and 
continuous  representations  of  the  model.  Flowever,  both  of  these  approaches  are  most  often  attempted 
(perhaps  after  appropriate  pilot  activities)  across  an  organization.  AIM  follows  a  project-by-project 
approach,  but  this  should  not  imply  that  the  structure  of  the  CMMI  is  ignored.  Rather,  the  PG  must 
utilize  both  the  structure  of  the  model  and  the  nature  of  AIM  methods,  in  conjunction  with  any  local 
practices,  to  craft  a  reasonable  strategy. 

Inherent  in  the  project-by-project  approach  of  AIM  is  a  strong  emphasis  on  the  project  management 
PAs  as  a  group.  TSP  covers  these  reasonably  well  [McFIale  2004,  Davis  2002].  Concurrent  with  this  is 
a  strong  emphasis  on  the  activities  being  planned  and  tracked,  which  for  the  noted  references, 
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corresponds  to  the  engineering  PAs,  especially  at  ML3.  The  largest  concentration  of  “gaps”  is 
clustered  in  the  ML3  process  management  PAs  (OPF,  OPD,  OT).  The  AIM  approach  of  launching  the 
PG  like  any  other  team  in  the  organization  exercises  the  project  management  strengths  again,  but 
shifts  the  focus  from  engineering  development  to  process  development,  thus  addressing  many  gaps  in 
an  organized  way. 

The  PG  models  the  desired  behavior  of  teams  within  AIM  in  several  ways.  First,  the  PG  is  trained, 
launched,  and  managed  and  coached  just  like  any  other  development  team  in  the  organization.  Second, 
the  nature  of  PG  work  forces  an  adaptation  of  TSP  methods  that  serves  as  an  exemplar  to  encourage 
other  teams  to  adapt  and  thus  truly  own  their  team  processes.  A  process  development  process,  for 
example,  is  provided  as  a  starting  point  for  any  such  activities,  along  with  unique  additional  team  roles 
that  serve  the  unique  purposes  of  the  PG.  Some  of  these  are  reflected  in  the  charts  in  Appendices 
dealing  with  Process  Definition  and  Organization  and  Project  Training. 

Coaching  the  PG  represents  a  challenge,  partly  because  such  a  team  is  unique  in  an  organization,  but 
also  because  of  the  breadth  and  depth  of  knowledge  needed  by  the  coach.  Ideally  the  coach  would  be 
both  a  qualified  TSP  coach  and  deeply  experienced  (if  not  formally  qualified)  in  CMMI -based 
improvement  and  appraisal.  However,  as  of  this  writing,  there  are  few  individuals  worldwide  who 
possess  both  skill  sets.  More  likely,  a  partnership  between  a  TSP  coach  and  a  CMMI  expert  will  be  the 
normal  minimum  expert  team.  The  Guide  for  SCAMPI  Appraisals:  Accelerated  Improvement  Method 
(AIM)  [Miluk  2010]  and  the  current  document  are  intended  to  help  bridge  that  particular  gap. 

The  PG  coach  should  recognize  that  almost  nothing  the  PG  does  affects  only  its  own  work.  The 
connections  from  the  “target”  PAs  of  the  PG — OPF,  OPD,  and  OT — correspond  explicitly  to  generic 
practices — GPs  2.5,  3.1  and  3.2 — which  span  potentially  all  engineering  activities  of  development 
teams,  not  to  mention  the  many  related  specific  practices  in  the  project  management  PAs.  In  addition, 
some  PGs  take  on  parts  of  one  or  more  of  the  support  PA  functions  as  a  matter  of  efficiency,  further 
strengthening  their  connections  across  projects  via  the  corresponding  GPs  (see  below).  Finally,  the  PG 
must  recognize  that  its  behavior  will  be  viewed  by  the  rest  of  the  organization  as  a  model  for 
development  teams.  It  therefore  becomes  even  more  important  for  the  PG  to  function  effectively — and 
in  some  sense  publicly — as  an  AIM  team,  since  a  valid  measure  of  their  success  will  be  in  how 
effectively  the  other  development  teams  function  in  the  new  environment. 

3.8  The  Support  PAs 

The  CMMI  support  PAs  covered  by  AIM  include  Measurement  and  Analysis  (MA,  addressed  above), 
Process  and  Product  Quality  Assurance  (PPQA),  Configuration  Management  (CM),  and  Decision 
Analysis  and  Resolution  (DAR).  During  the  initial  gap  analysis  that  formed  the  starting  point  for  the 
Guide  for  SCAMPI  Appraisals:  Accelerated  Improvement  Method  (AIM)  [Miluk  2010],  PIPs  were 
generated  to  address  gaps  found  for  each  of  these  areas.  These  PIPs  are  included  in  Appendix  D  as  an 
aid  to  organizations  executing  UC2,  namely  implementing  AIM  on  an  existing  base  of  TSP  practices, 
since  this  information  should  help  to  highlight  changes  in  their  baseline  of  TSP  practices. 

For  both  PPQA  and  CM,  the  PIPs  reflect  the  fact  that  the  project-oriented  TSP  processes  basically 
acknowledged  the  existence  of  and  interactions  with  these  PA  practices,  but  did  not  attempt  to  directly 
implement  them.  For  example,  CM  is  acknowledged  by  the  designation  of  the  TSP  Support  Manager 
role  as  having  principal  CM  duties  for  the  team,  and  with  direct  CM  items  being  planned  during  the 
TSP  launch,  especially  launch  meeting  3 .  Quality  assurance  activities  are  spread  across  several  roles 
and  are  distinguished  at  least  partially  by  process  QA  (TSP  coach  role,  TSP  team  leader  role,  process 
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and  quality  manager  roles)  and  product  QA  (TSP  team  leader,  test  manager  role,  and  other  roles 
depending  upon  the  products  in  question). 

However,  when  applying  SCAMPI-like  tests  for  the  existence  and  adequacy  of  process  artifacts,  it 
became  apparent  that  some  activities  that  TSP  considered  optional  became,  if  not  required,  at  least 
very  strongly  suggested  in  order  to  leave  an  artifact  trail  for  a  SCAMPI  appraisal  team.  Thus,  the 
answer  to  the  question  of  whether  TSP  team  role  activities  related  to  these  practices  should  be 
included  in  a  team  member’s  individual  workbook  changes  from  “it’s  optional”  or  “it’s  up  to  the 
individual”  to  “yes,  this  work  should  be  planned  and  tracked  just  like  any  other.”  By  planning  and 
tracking  these  tasks  in  individual  workbooks,  an  artifact  trail  for  specific  and  generic  practices  is 
created  as  the  work  is  done. 

3.8.1  Configuration  Management  (CM)  and  GP  2.6 

Configuration  Management  (CM)  provides  the  best  example  of  how  AIM  and  existing  practices 
should  co-exist.  It  is  almost  unthinkable  that  any  modem  software  development  organization  has  no 
existing  configuration  management  practice.  Excellent  CM  tools  are  available  commercially  and 
freely  in  open  source,  and  rudimentary  CM  is  built  into  many  modem  development  environments. 
However,  it  is  almost  impossible  for  any  tool  to  fully  implement  even  one  specific  practice  in  any  PA, 
let  alone  the  seven  within  CM,  without  mindful  direction  from  skilled  practitioners. 

The  Configuration  Management  chart  in  Appendix  A  shows  the  formal  AIM  solution,  a  solution  that 
goes  in  a  different  direction  than  the  one  specified  in  PIP  CM-1.  The  AIM  solution  includes  primary 
interactions  between  someone  wishing  to  update  or  place  an  artifact  under  configuration  control  (most 
typically  a  product  owner)  and  the  support  manager  role,  with  additional  interactions  with  the  design 
manager  and  process  manager  roles,  and  the  CCB  (Configuration  Control  Board,  an  entity  defined  in 
the  TSP  launch  if  not  already  in  existence).  Certain  TSP+  process  assets  referred  to  in  the  chart 
provide  specific  guidance  and  capture  necessary  information.  If  a  team  executes  the  actions  on  this 
chart  appropriately  and  consistently,  along  with  other  actions  specified  in  the  support  manager  role 
description,  TSP  launch  scripts,  and  when  enacting  well-composed  development  scripts,  compliance 
with  CM  practices  is  virtually  assured. 

However,  AIM  provides  a  purely  paper-based  solution,  while  real-world  CM  for  almost  any  project  is 
going  to  use  one  or  more  of  the  aforementioned  automated  tools,  and  possibly  well-established 
procedures  for  their  use.  The  AIM  recommendation  is  not  to  throw  out  the  existing  CM,  but  rather  to 
understand  the  requirements  of  missing  or  inadequate  CMMI  practices  and  what  is  provided  by  the 
relevant  AIM  specifics,  to  use  that  understanding  along  with  whatever  AIM  assets  make  sense  under 
the  circumstances,  and  then  to  devise  a  solution  that  adds  value  for  the  team  and  organization  while 
fully  conforming  to  CMMI.  The  least-effort  solution  is  that  existing  CM  practices  suffice  both  for  the 
team’s  and  organization’s  purposes,  and  for  CMMI — perfectly  acceptable  under  AIM.  In  another  case, 
some  element  of  CMMI  is  lacking  in  the  existing  implementation,  and  between  the  AIM 
recommendation  and  the  actual  text  of  the  CMMI,  some  intelligent  selection  or  adaptation  of  AIM 
parts  will  fit  the  need  and  provide  benefit  to  the  effort. 

This  is  the  preferred  implementation  mode  for  AIM  practices  beyond  the  basics  of  TSP  introduction 
and  SCAMPI  appraisals:  understand  what  already  exists,  understand  the  intent  of  the  model  and  what 
is  missing  or  inadequate,  understand  what  AIM  can  provide,  and  then  formulate  and  verify  a  solution 
that  provides  value  to  the  project  team  and  to  the  organization. 
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3.8.2  Process  and  Product  Quality  Assurance  (PPQA)  and  GP  2.9 


The  subject  of  QA  (quality  assurance)  is  often  a  sensitive  one,  especially  with  development  teams.  No 
activity  in  an  organization  seems  more  prone  to  abuse,  whether  by  a  mindless  check-the-box  mentality 
or  by  a  punitive,  audit-like  approach.  In  fact,  a  common  anxious  question  in  PSP  and  TSP  training  is, 
“What  is  management  going  to  do  with  this  data?” 

The  AIM  approach  to  quality  assurance  is  multi-layered  and  somewhat  diffuse,  and  with  proper 
safeguards  in  place,  should  co-exist  smoothly  with  existing  QA  practices  and  allay  any  concerns  about 
management’s  use  of  detailed  personal  data.  Rather  than  implementing  the  somewhat  obvious 
suggestion  in  PIP  QA-I,  AIM  emphasizes  the  use  of  existing  roles  and  processes  in  a  manner  fully 
consistent  with  their  intended  use,  to  ensure  that  processes  are  consistently  executed  in  order  to  deliver 
excellent  products. 

As  mentioned  previously,  process  quality  assurance  and  product  quality  assurance  are  addressed 
separately  but  in  similar  manners.  Both  begin  with  the  individual  team  member  who  executes  a 
defined,  measured  process  to  produce  a  product  to  a  specified  standard.  Parts  of  that  process  typically 
specify  personal  reviews  by  the  developer,  team  inspections,  and  some  level  of  testing  by  the 
developer — product  checks.  The  process  manager  role  monitors  compliance  with  the  plan — process 
checks. 

The  team  leader,  who  is  ultimately  responsible  to  management  for  the  product,  and  the  TSP  coach, 
who  is  ultimately  responsible  for  the  process,  each  have  their  own  overlapping  checks.  The  team 
leader  runs  the  weekly  data-driven  team  meetings,  sees  how  the  product  development  is  progressing, 
and  hears  reports  from  the  process,  quality,  and  test  managers.  The  TSP  coach,  following  a  coaching 
plan  developed  during  the  launch,  sits  in  on  early  weekly  meetings  and  occasionally  may  do  so  later  in 
the  project,  and  reviews  workbooks  on  a  periodic  basis.  On  request  from  a  role  manager  or  the  team 
leader,  or  based  on  the  workbook  review,  the  coach  may  conduct  a  TSP  checkpoint,  with  or  without  a 
formal  report  to  management,  in  order  to  identify  any  issues  with  gathering  data  or  following  the 
agreed-to  processes.  The  coach  may  also  do  specific  role-based  coaching  for  the  team  leader  and  team 
members  in  the  use  of  a  tool  or  specific  processes,  or  with  respect  to  executing  a  particular  team  role. 
Significant  artifacts  for  a  SCAMPI  appraisal  include  role  descriptions  for  the  TSP  coach,  team  leader, 
team  members,  and  other  relevant  roles;  workbooks  that  document  and  track  the  coaching  plan  and  the 
various  team  roles;  weekly  meeting  minutes  that  record  the  role  manager  reports  and  any  QA  issues; 
and  the  TSP  coach’s  checkpoint  reports. 

This,  then,  is  the  basic  model  for  QA  in  AIM:  three  tiers  of  overlapping  checks,  first  by  the  individual 
team  member  against  his  or  her  own  process  and  plan,  second  by  the  team  roles,  and  finally  by  the 
team  leader  and  TSP  coach.  Non-compliances  can  be  reported  at  any  level  and  escalated  as  necessary; 
however,  the  emphasis  and  preference  is  that  non-compliances  are  corrected  immediately  by  the 
people  involved.  If  a  process  cannot  be  followed  consistently,  it  is  changed.  If  a  tool  is  being  used 
improperly,  remedial  instruction  is  provided  immediately.  If  a  team  is  generally  unable  to  follow  its 
plan,  usually  this  is  because  the  plan  is  outdated  or  based  on  false  assumptions,  in  which  case  a  replan 
or  relaunch  is  necessary. 

This  approach  is  also  consistent  with  a  more  traditional  approach  to  quality  assurance.  The  typical 
AIM  team  creates  detailed  records  of  their  activities  as  a  matter  of  course  and  on  a  daily  basis,  and 
early  organizations  implementing  CMMI  (and  before  it,  SW-CMM)  certainly  took  this  traditional 
approach  utilizing  existing  QA  personnel  and  procedures  [Wall  2007].  However,  this  did  not  change 
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or  diminish  the  approach  described  above.  AIM  teams  take  responsibility  for  the  quality  of  what  they 
deliver,  and  recognize  explicitly  that  such  quality  relates  directly  to  the  processes  that  they  use,  and  to 
the  fidelity  and  discipline  with  which  they  execute  those  processes. 

3.8.3  Decision  Analysis  and  Resolution 

Decision  Analysis  and  Resolution  (DAR)  is  a  somewhat  odd  process  area.  It  has  no  obvious  relation  to 
generic  practices  like  the  other  support  PAs.  It  lives  alone  in  the  support  category  at  ML3.  Yet  in  some 
ways,  it  is  the  most  useful  and  ubiquitous  PA  of  all.  Consider  that  an  organization  just  starting  out  on  a 
process  improvement  effort  must,  rather  obviously,  decide  what  improvement  model  or  models  to  use 
as  a  guide,  and  what  methods  to  use  to  implement  those  models.  This  seems  like  an  important  enough 
decision  to  establish  evaluation  criteria  and  methods,  identify  and  evaluate  alternatives,  and  then  select 
from  among  those  alternatives  how  to  proceed.  Most  of  DAR  can  be  executed  before  the  effort 
formally  begins. 

In  fact,  this  pattern  repeats  over  and  over  again  in  a  process  improvement  setting,  a  project 
management  setting,  or  a  development  setting.  Any  decision  important  enough  in  terms  of  money, 
personnel,  strategic  direction,  or  any  number  of  business  or  technical  considerations  can  benefit  from 
a  formal  decision  analysis  process  consistent  with  DAR,  and  many  are  possible.  TSP+  provides  a 
script  and  accompanying  form  to  guide  a  fairly  generic  DAR  capability,  but  many  different  decision 
analysis  disciplines  may  (and  perhaps  should)  exist  in  any  organization.  Sometimes  an  entire  project  is 
launched  that  recognizably  fits  the  DAR  specific  practices,  for  example,  to  choose  between  two 
competing  high-speed  communications  products  for  a  business-critical  real-time  transaction¬ 
processing  system. 

The  organization’s  PG  and  its  TSP  coach  should  be  aware  of  the  DAR  script  and  use  it  as  appropriate, 
while  keeping  in  mind  that  it  is  one  minimally  acceptable  example  of  formal  decision  analysis.  When 
building  project  plans  for  development  teams  and  for  the  PG,  decision  points  can  often  be  identified 
that  would  benefit  from  the  use  of  DAR,  while  incidentally  creating  the  artifacts  of  interest  to  a 
SCAMPI  team.  Tool  decisions,  project  strategy  decisions,  architectural  decisions,  AIM  rollout 
decisions — all  of  these  are  opportunities  to  exercise  the  DAR  script  and  benefit  from  the  formal 
analysis. 

3.9  Stakeholder  Involvement — GP  2.7 

PIP  PP-3  in  Appendix  D  points  out  a  paper  weakness  in  the  previous  version  of  TSP,  namely  that 
there  was  no  consistent  documented  method  of  planning  the  involvement  of  identified  stakeholders. 
The  phrase  “paper  weakness”  is  used  because,  in  practice,  stakeholder  involvement  was  typically  a 
strength  of  TSP  because  the  transparency  of  its  project  status  simplified  the  involvement  of  relevant 
parties  at  critical  points  in  the  project.  However,  “typically”  does  not  mean  “always,”  and  almost 
every  active  TSP  coach  can  name  an  instance  when  some  relevant  stakeholder  slipped  through  the 
planning  cracks,  which  caused  a  problem  later  on. 

The  Stakeholder  Involvement  chart  in  Appendix  A  describes  the  AIM  approach  to  identifying  and 
planning  interactions  with  important  stakeholders  by  linking  their  involvement  with  specific  TSP+ 
process  elements  (form  RSIM,  Relevant  Stakeholder  Assigmnent  Matrix)  to  specific  TSP+  team  roles 
(form  SRAM,  Stakeholder  Role  Assigmnent  Matrix).  (A  complete  list  of  TSP+  process  elements  is 
provided  in  the  Guide  for  SCAMPI  Appraisals:  Accelerated  Improvement  Method  (AIM)  [Miluk 
2010].)  This  reflects  a  common  way  that  TSP  teams  have  dealt  with  their  stakeholders  in  the  past,  but 
as  with  most  of  AIM,  this  is  not  intended  as  the  exclusive  method  of  dealing  with  this  issue.  Many 
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robust  project  management  disciplines,  formal  and  informal,  explicitly  recognize  the  importance  of 
stakeholder  identification  and  involvement. 

3.10  What  About  the  Other  GPs? 

Generic  practices  (GPs)  in  the  CMMI  are,  in  some  sense,  part  of  the  skeletal  structure  of  CMMI. 

Every  PA  includes  them,  and  they  form  a  logical,  repeatable  pattern  that  reflects  an  organizing 
philosophy  underlying  CMMI.  Whether  the  activities  to  be  performed  are  engineering,  project  or 
process  management,  or  support,  those  activities  should  be  assigned  to  properly  trained  and  equipped 
personnel,  be  planned  and  tracked  based  on  practices  that  have  worked  before,  have  important 
artifacts  placed  under  appropriate  configuration  control,  be  subjected  to  objective  scrutiny,  be 
summarized  for  and  reviewed  by  senior  management,  and  then  be  made  available  for  analysis  and 
possible  future  use  across  the  organization. 

PSP  training  and  TSP  teams  show  their  true  power  in  this  regard.  The  basics  of  using  defined 
processes  that  are  planned,  performed,  measured,  and  tracked  are  fundamental  to  working  on  a  TSP 
team,  and  all  of  these  are  evident  in  the  artifacts  that  such  teams  naturally  produce.  Obviously,  this 
reflects  well  when  a  SCAMPI  appraisal  team  looks  at  such  a  team’s  activities  as  measured  against  the 
yardstick  of  CMMI.  However,  the  team  is  not  working  in  this  fashion  in  order  to  look  good  in  the 
SCAMPI,  it  works  this  way  because  it  gets  the  job  done  right  the  first  time. 

3.11  Engineering  Practices 

The  issue  of  implementing  engineering  practices,  especially  in  the  light  of  a  SCAMPI  appraisal,  is  in 
some  ways  the  easiest  for  AIM  to  address,  and  in  some  ways  the  hardest.  It  is  easiest  in  the  sense  that, 
as  will  be  explained  below,  there  is  relatively  little  in  the  way  of  standard  AIM  process  assets  to 
understand  and  implement.  But,  it  is  hardest  in  the  sense  that  the  full  implementation  of  “engineering 
practices”  as  specified  in  the  PAs  for  Requirements  Management  (REQM — 5  SPs),  Requirements 
Development  (RD — 10  SPs),  Technical  Solution  (TS — 8  SPs),  Product  Integration  (PI — 9  SPs), 
Verification  (VER — 8  SPs),  and  Validation  (VAL — 5  SPs),  plus  the  associated  generic  practices, 
could  represent  the  largest  amount  of  implementation  effort  by  an  organization  using  AIM. 

PIPS  ENGR-1,  ENGR-2,  ENGR-3,  and  REQM-1  (shown  in  Appendix  D)  describe  the  issues  with  the 
engineering-related  TSP+  scripts.  The  process  scripts  that  cover  an  idealized  engineering  life  cycle — a 
CYCLE  script  (see  Appendix  B)  that  points  to  a  DEV  script  for  new  development,  a  MAINT  script  for 
maintenance  work,  each  of  which  in  turn  point  to  several  other  subordinate  scripts  for  particular  parts 
of  each  life  cycle — are  fairly  high  level  and  generic,  and  eventually  refer  to  artifacts  such  as  an 
Engineering  Requirements  Specification  (ERS),  System  Requirements  Specification  (SRS),  or 
Software  Design  Specification  (SDS).  These  artifacts  have  no  existence  in  TSP  outside  of  these 
scripts — no  templates,  no  specifications,  no  exemplars,  only  names.  The  assumption  is  that  these  are 
placeholder  scripts  and  artifacts  that  would  be  supplanted  by  an  organization’s  existing  engineering 
life  cycles,  including  templates,  exemplars,  and  specifications  as  needed. 

In  most  cases,  this  is  exactly  how  the  engineering  scripts  are  used,  with  occasional  reference  to  them 
in  terms  of  using  the  given  scripts  as  checklists  to  ensure  that  the  local  engineering  processes  used  by 
the  team  didn’t  miss  any  items  deemed  important  enough  to  be  mentioned  by  AIM.  However,  when 
evaluating  the  baseline  TSP  or  even  TSP+  for  SCAMPI  C  purposes,  the  “paper  only”  evaluation  came 
up  short  [Miluk  2010], 
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In  deciding  how  to  address  these  gaps,  there  is  no  intention  within  AIM  to  direct  engineers, 
developers,  and  the  teams  that  they  work  on.  Rather,  it  is  part  of  the  team’s  job,  as  in  “standard”  TSP, 
to  define  the  way  that  it  works — which  can  mean  simply  using  the  organization’s  existing  practices 
within  the  TSP  management  and  measurement  framework — and  then  capturing  those  definitions.  The 
PG  provides  support  as  needed  and  then  collects  such  definitions  for  possible  inclusion  in  the 
organization’s  process  asset  library,  along  with  the  associated  estimated  and  actual  performance 
measurements. 

So,  while  a  large  majority  of  process  management,  project  management,  and  support  CMMI  practices 
are  addressed  directly  by  AIM,  there  are  no  shortcuts  to  implementing  engineering  practices  in  any 
given  organization.  The  development  team,  the  PG,  the  TSP  coach,  and  the  CMMI  expert  must  work 
together,  often  with  additional  parties  from  within  the  organization.  This  is  especially  critical  in  larger 
organizations.  As  a  general  rule,  the  larger  an  organization  becomes,  the  less  likely  it  is  that 
development  teams  or  even  the  PG  will  have  the  entire  scope  of  engineering  practice  within  their 
direct  control.  Marketing  is  likely  to  be  heavily  involved  in  requirements  elicitation  and  validation.  A 
project  management  office  may  own  critical  pieces  of  the  requirements  management  process.  A  test 
department  may  own  the  later  parts  of  the  life  cycle.  In  these  cases,  the  relevant  parts  of  the  life  cycle 
guided  by  CMMI  specific  practices  must  be  addressed  by  more  conventional  means;  however,  the 
development  team  is  well-advised  to  exercise  the  stakeholder  involvement  mechanisms  described 
above  to  engage  other  groups  and  individuals  constructively. 

The  good  news  here  is  that  competent  development  organizations,  almost  by  definition,  will  already 
be  performing  a  significant  number  of  the  45  CMMI  engineering  specific  practices.  AIM  training  and 
methods  provide  a  generic  practice  framework  that  are  known  to  work  with  a  wide  range  of  methods, 
from  agile  practices  of  all  descriptions  to  the  most  demanding  aspects  of  formal  architecture, 
implementation,  and  security  methods.  The  first  pilot  projects  are  usually  critical  for  characterizing 
engineering  practices  by  providing  the  disciplined  framework  that  focuses  on  producing  the  artifacts 
and  activity  trail  for  which  SCAMPIs  are  looking. 

3.12  Additional  Guidance  for  TSP  Teams 

For  organizations  with  a  pre-existing  TSP  implementation,  even  the  best  of  such  implementations 
must  look  for  the  differences  in  TSP+.  These  begin  with  launch  preparations,  which  have  become 
more  extensive  and  explicit,  in  part  to  ensure  that  CMMI-visible  practices  move  from  the  category  of 
“implicit/usually  done”  to  “explicit/always  done.”  The  experienced  TSP  coach,  team  leader,  and 
development  team  should  pay  particular  attention  to  the  updated  PREPL  checklist  and  more  recent 
PREPT  script.  It  is  also  advised  that  the  TSP  coach  and  the  team’s  process  manager  take  time  to  study 
the  changes  made  to  existing  TSP  scripts,  forms,  specifications,  etc.  as  depicted  in  the  activity  charts 
shown  in  Appendix  A. 

In  a  similar  vein,  TSP  role-based  activities  that  were  left  to  the  discretion  of  teams  and  individuals  to 
plan  and  track  (either  formally  or  informally)  are  now  directed  to  capture  all  of  these  activities 
formally.  The  original  role  manager  responsibilities,  with  only  a  few  updates,  are  essential  to  the 
performance  of  many  CMMI  specific  and  generic  practices,  as  indicated  throughout  the  Guide  for 
SCAMPI  Appraisals :  Accelerated  Improvement  Method  (AIM)  [Miluk  2010].  This  also  puts  added 
emphasis  on  the  roles  of  the  TSP  coach  and  team  leader,  and  in  the  case  of  the  TSP  coach,  a  coach 
role  specification.  Thus  TSP+  corrects  an  historical  irony,  namely  the  lack  of  a  TSP  role  description 
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for  the  coach.  The  TSP  coach  role  is  described  in  an  entire  book  [Humphrey  2006]  and  in  the  five-day 
SEI  course  TSP  Coach  Training 9,  but  previously  had  no  specification  within  TSP. 

3.13  Concerning  Six  Sigma 

Six  Sigma  has  a  long  pedigree  in  manufacturing,  longer  than  CMMI  has  been  used  for  software  and 
systems  engineering  (even  if  one  includes  the  CMM  for  Software  in  the  age  of  CMMI).  Training 
programs  for  the  various  colors  of  Six  Sigma  belts  vary  widely,  but  are  nevertheless  grounded  in  the 
same  basic  statistical  and  procedural  techniques  incorporated  into  CMMI,  especially  at  the  higher 
maturity  levels,  and  are  widely  available.  Tens  of  thousands  have  been  trained  in  and  used  these 
techniques  with  extraordinary  results. 

Yet,  very  little  specific  guidance  is  given  here  for  the  use  of  Six  Sigma  methods  beyond  the  most 
general  suggestions  of  timing  and  expertise.  The  reasons  for  this  are  likely  obvious  to  Six  Sigma 
Black  Belts  and  other  experts,  who  know  only  too  well  that  the  proper  application  of  the  methods 
requires  a  sophisticated  understanding  of  the  particulars  of  the  organizations,  the  projects,  the 
processes,  and  the  data  available.  By  the  time  such  an  expert  knows  enough  about  such  things  in  order 
to  guide  intelligently,  that  person  needs  no  further  general  instruction  from  this  document.  However,  a 
few  more  words  to  others  involved  in  such  an  effort  may  be  useful. 

As  discussed  below,  Six  Sigma  provides  a  likely  bridge  to  CMMI  high  maturity  once  the  basic  goals 
of  AIM — achieving  high  performance  in  business  tenns  with  solid  CMMI  ML3  confonnance — are 
met.  However,  some  such  techniques  can  be  of  great  value  in  achieving  those  goals.  For  example, 
Voice  of  the  Customer  techniques  can  be  used  to  good  effect  for  at  least  the  Requirements 
Development  and  Validation  practices.  This  is,  of  course,  only  one  example.  Consult  the  local  Six 
Sigma  Black  Belt  for  further  guidance. 

3.14  Preparing  for  High  Maturity 

As  mentioned  previously,  the  targeted  CMMI  scope  of  AIM  excludes  maturity  levels  4  and  5, 
collectively  and  commonly  referred  to  as  “high  maturity.”  The  reasons  for  this  exclusion  are 
historical  and  practical.  Historically,  while  Six  Sigma  methods  have  been  used  successfully  to  move 
organizations  to  high  maturity  and  enhance  the  operations  of  those  already  at  ML5  [Stoddard  2008], 
the  majority  of  experiences  of  TSP-using  organizations  that  have  achieved  ML4  or  better  did  so  with 
the  CMM  for  Software  (SW-CMM)  as  a  reference  model.  This  document  relies  heavily  on  the 
experiences  of  TSP  users  for  useful  information.  The  experience  base  for  CMMI  high  maturity  using 
TSP  is  simply  insufficient. 

Even  assuming  that  the  information  was  available,  practical  considerations  argue  against  including 
high  maturity  guidance  here.  CMMI  high  maturity  requires  that  baselines  and  models  specific  to  the 
data  and  processes  of  a  particular  organization  are  accumulated  and  developed.  It  seems  likely  that 
effective  guidance  for  such  activities  will  be  quite  lengthy,  and  in  light  of  the  discussion  above 
concerning  Six  Sigma’s  use,  possibly  unnecessary. 

However,  it  also  seems  clear  that  the  detailed  data  provided  by  TSP  teams  provide  a  more  solid 
foundation  for  building  the  baselines  and  rich  statistical  models  for  CMMI  high  maturity  practices 
than  measurement  regimens  built  only  on  team-  or  project-level  data.  For  example,  individual  time 
and  defect  data  are  used  to  update  personal  review  checklists  using  only  the  most  basic  statistical 

9  TSP  Coach  Training,  http://www.sei.cmu.edu/traininq/p21.cfm. 
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techniques.  Not  only  is  such  data  already  an  invaluable  business  and  professional  asset,  the  potential 
of  using  such  data,  aggregated  across  and  between  project  teams  and  properly  segregated  and  analyzed 
using  Six  Sigma  and  other  techniques,  seems  enormous. 
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Appendix  A:  Activity  Charts  for  Selected  Processes 


The  following  activity  charts  are  a  useful  aid  to  understanding  several  of  the  new  process  capabilities 
within  TSP+.  Note  that  they  do  not  cover  all  of  the  new  capabilities. 

The  charts  generally  show  how  affected  roles  (listed  at  the  top  of  each  chart)  use  a  script,  form,  or 
checklist  to  perform  the  intended  activities.  The  activities  have  been  designed  to  add  value  to  team 
activities  while  complying  with  relevant  CMMI  practices. 

Table  2:  Selected  TSP+  Activity  Flows 


Chart  Name 

Description 

Affected  TSP  Roles 

Configuration 
Management  (CM) 

Two  charts  documenting  the  intended 
flow  of  configuration  management 
activities 

Support  manager,  team  member/product  owner, 
quality  and  process  managers,  CCB  (Configuration 
Control  Board,  team  level 

CM — Configuration 
Change  Requests 

Documents  the  flow  for  formal  change 
requests 

Requestor,  support  manager,  affected  project  team, 
CCB,  affected  product  owner  or  role  manager 

Stakeholder 

Involvement 

Documents  the  usage  of  the  new 
stakeholder  involvement  mechanisms 

Team  members,  team  leader,  process  group,  team 
management,  process  manager 

Process  Definition 

Four  charts  documenting  the  many 
interactions  between  the  various  roles 
involved  in  formal  process  definition 

Team  members,  process  and  support  managers, 
process  group,  management 

Organizational  and 
Project  Training 

Four  charts  showing  the  many 
interactions  between  the  various  roles 
involved  in  planning  and  tracking  training 
activities 

Team  members,  team  leader  and/or  management, 
training  manager  (new  role  on  the  process  group), 
process  group,  training  attendees  and  instructors 

Periodic  Review  of 
Training  Matrix 

An  additional  chart  for  training  activities  to 
close  the  loop  on  the  training  activities 

Team  members,  team  leader  and/or  management, 
training  manager  (new  role  on  the  process  group), 
process  group,  training  attendees  and  instructors 

Decision  Analysis 
and  Resolution 

One  way  to  perform  DAR,  certainly  not 
the  only  way 

Team  or  team  member,  decision  owner,  decision 
participants  and  stakeholders,  process  manager 
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Configuration  Management -Configuration  Change  Requests 


Request  Originator 


Team 


Support  Manager 


Product  Owner 
And 

Role  Manager 


Configuration 
Control  Board 
(COB) 


1.  Usually  these 
effort  to  change 
configuration  ba 
given  Cl  release 
implementation 
written  against  a 
given  release 
changes  to  requi 

2.  This  process 
designed  to  man 


t  le 
se  [ 


are  items  which  are  not 
ill  related  CIs.  Such  as 
eline  set.  Normally  a 
For  example  a  software 
c  f  multiple  change  reque 
set  of  requirements,  but 
Ttiose  approved  and  alloi 
ements  documentation, 
i  not  used  to  establish  o 
age  the  technical  CIs. 


ihanged  easily  or  requirt 
CIs  that  make  up  a  pi 
of  change  requests  are 
product  release  may  co 
ts.  Several  change  req 
only  a  few  are  approvec 
c  ated  change  requests 
design  documentation, 
maintain  the  OSSP  or 


a  coordinated 
rfcduct’s 

implemented  in  a 
isist  of  the 
lests  might  be 
and  allocated  to  a 
ay  result  in 
the  code. 

I  SSP.  It  is 


n 

t  nd  I 


[Follow  Configuratior 
[Management  flow  di  agram 


langes  required  within  a 
’  i  lycle.  It  would  be 
ad  for  and  executed  as 
ad  growth. 
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Stakeholder  Involvement 


Team  Member  or 
Team 


Team  Leader 


Process  Group 


Management 


Planning  Manager 


Team  Launch 
Preparation 
Script  PREPT 
(Team) 


I 


Team  Launch 
Preparation 
Checklist 
PREPT 


< 


Team  Leader  reviews  the  RSIM  with  team,  process  group  and  management  for  completeness 


/ 

\ 


Launch  Meeting  8 
Script  LAU8 
(Team  reviews 
SRAM  and  RSIM) 


f 


Relevant 

Stakeholder 
Involvement  Matrix 
Form  RSIM 
(Update) 


Begin  mapping 

individuals  to  the 
roles  identified  in 
form  RSIM  using 
the  project’s 
SRAM. 


\ 

/ 


Stakeholder  Role 
Assignment  Matrix 
Form  SRAM 
(Update) 


jr 


Relevant 

Stakeholder 
Involvement  Matrix 
Form  RSIM 
(Update 

Stakeholder  Role 
Assignment  Matrix 
Form  SRAM 
(Update) 


Relevant 

Stakeholder 
Involvement  Matrix 
Form  RSIM 
(Update 


Stakeholder  Role 
Assignment  Matrix 
Form  SRAM 
(Update) 


> 


,  r 


Launch  Meeting  9 
Script  LAU9 

Management  and  the  process  group  review  the  RSIM 
and  the  SRAM  for  completeness  and  approval. 
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Process  Definition 


Team  Member  or 
Team 

V 

Team  Launch 
Preparation 
Script  PREPT 
(Team) 

Team  Launch 
Preparation 
Checklist 
PREPT 


Process  Manager 


Process  Group 
(New  Role) 


Launch  Meeting  3 
Script  LAU3 


Process  Manager  obtains  a  copy  of  the 
OSSP  from  the  Process  Group’s 
configuration  management  coordinator 


Standard  Process 
Deviation 
Summary 
Form  SUMPD 


Management 


Support  Manager 


'  Support  Manger 
configures 
PSSP  by 
following  the 
configuration 
management 
processes 


\ 

/ 


Form  CIBPS 
(Add  PSSP) 
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Process  Definition 


Team  Member  or 
Team 


Process  Manager 


Process  Group 
(New  Role) 


Management 


Support  Manager 


_ 


Process  Manager  leads  the  team  in  defining  the 
development  process  by  reviewing  the  PSSP 
(Form  CIBPS)  to  determine  if  the  standards 
meet  project  needs  and  how  they  need  to  be 
tailored  or  deviated  (Form  SUMPD). 


Standard  Process 
Deviation 
Summary 
Form  SUMPD 
(Update) 


< 


Make  plan  to  develop,  modify,  or  obtain 
each  missing  process  element. 


Launch  Meeting  8 
Script  LAU8 
(Prepare  for  meeting  9 
in  accordance  with  the 
TSP  Management 
Briefing  Guidelines) 


Launch  Meeting  9 
Script  LAU9 
(Present  proposed 
changes  to  the  PSSP 
using  From  SUMPD) 


> 


Management  and  Progress  Group  Lead 
initially  agree  to  proposed  changes  to  the 
PSSP,  pending  formal  process  deviation 
approvals  (Form  SPDR) 


\ 

\  including  rationale  I 
\  for  deviation  and  / 
\  evaluation  criteria  / 

\  for  approval.  / 

s 


Document  process 
elements  effected 
by  each  process 
deviation  (found  in 
From  SUMPD), 
including  rationale 
for  deviation  and 
evaluation  criteria 
for  approval. 
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Process  Definition 


Team  Member  or 
Team 


Process  Manager 


Process  Group 
(New  Role) 


Management 


Support  Manager 


f  Compare  SPDR  to  \ 
other  SPDRs  to 
ensure  no  conflicts 
have  occurred  and 
compare  SPDR  to 
the  team’s  goals  to 
ensure  that  the 
SPDR  does  not 
prevent  the  team 
from 

accomplishing  its 
objectives. 
Resolve  all  issues 
then  sign  and  date 
SPDR. 


-  Update  PSSP  with  approved  process 
deviations. 

-  Configure  process  changes  (Form  CIR) 


-  Enter  SPDR  into 
LOGSPDR 
-Compare  the 
SPDR  to  the 
organization’s 
business  goals 
and  objectives. 
Resolve  all  issues, 
then  sign  and  date 
SPDR 


\ 

/ 


Standard  Process 
Deviation  Request 
Log 

Form  LOGSPDR 


Standard  Process 
Deviation  Request 
Log 

Form  LOGSPDR 
(Update  Status) 


K  Approve  or 

Disapprove  SPDR.  J 


<  Inform  Process  X 

Manager  of  ^ 
Approval  or  / 
Disapproval  / 


f  Support  Managers 

configures 
changes  to  the 
PSSP  by 
following  the 
configuration 
management 
processes 
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Process  Definition 


Team  Member  or 
Team 


Process  Manager 


Process  Group 
(New  Role) 


Management 


Support  Manager 


/ 

\ 


Execute  TSP  plan  1 
for  current  Launch 
cycle,  or  phase, 
following  the 
PSSP  with 
approved 
deviations. 


TSP  Postmortem 
Script  PM 
(--Review  all 
approved  process 
deviation  requests 
(Form  SPDR)  and 
document  evaluation 
results  (Form  SPDE). 
—  Review  PSSP  to 
identify  items  to  be 
tailored  (Form 
SUMPD)  based  on 
next  launch/phase  or 
project  requirements 
and  SPDE 
recommendations. 
—  Review  Cl  BPS  for 
continued 
applicability  of 
unimplemented 
changes  to  the  PSSP 
based  on  next 
launch/phase  or 
project  requirements) 


—  Compare  SPDE 

to  SPDR  to 
ensure  all  aspects 
of  the 

effectiveness 
evaluation  criteria 
of  the  SPDR  has 
been  addressed 
by  the  SPDE. 

—  Enter  the 
SPDE’s 
associated 
SPDR’s  control 
number 

—  Address  issues, 
then  sign  and 

data  approval  line. 


Standard  Process 
Deviation 
Evaluation  Form 
Form  SPDE 
(one  for  each 
approved  SPDR) 


Process  Improvement 
Proposal 
Form  PIP 


-  Compare  SPDE 
to  SPDR  to  ensure 

all  aspects  of  the 
effectiveness 
evaluation  criteria 
of  the  SPDR  has 
been  addressed  by 
the  SPDE. 

—  For  “Successful” 
team 

recommendations, 
compare  SPDR 
and  SPDE  to 
associated  PIP  to 
ensure  consistency 
and  that  sufficient 
information  has 
been  collected  to 
implement  PIP. 
--Address  issues, 
then  sign  and  date 
approval  line. 


Standard  Process 
Deviation  Request 
Log 

Form  LOGSPDR 
(update  status) 


Store  approved 
SPDR,  SPDE  and  , 
associated  PIPs 
for  future 
reference  and  ' 
possible 

incorporation  into 
the  OSSP 
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Organizational  and  Project  Training  (New  Specification  TRN) 


Team  Member  or 
Team 


Training  Manager 
(New  Role) 


Team  Leader  or 
Management 


Training  Attendee 
or  Instructor 


Process  Group 


Team  Launch 
Preparation 
Script  PREPT 
(Team) 


Team  Launch 
Preparation 
Checklist 
PREPT 


Team  leader  meets  with  training 
manager  to  ensure  that  all  team 
members,  including  self,  have 
obtained  all  required  training  and 
to  obtain  list  of  all  outstanding 
training  requirements  and 
schedule  for  all  mandatory 
training. 
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Organizational  and  Project  Training  (New  Specification  TRN) 


Team  Member  or 
Team 


Training  Manager 
(New  Role) 


Team  Leader  or 
Management 


Training  Attendee 
or  Instructor 


Process  Group 


Training  Waiver 
Request  Form 
Form  TRNWR 


Training  Waiver 
Request  Form 
Form  TRNWR 
(Evaluate  Request) 


Apf  roved 
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Organizational  and  Project  Training  (New  Specification  TRN) 
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Organizational  and  Project  Training  Periodic  review  of  Training  Matrix 


Team  Member  or 
Team 


Training  Manager 
(New  Role) 


Team  Leader  or 
Management 


Training  Attendee 
or  Instructor 


Process  Group 


< 


The  Training  Manager  must  periodically  review  the  Training  Matrix  (form  TRNM)  with  teams,  projects,  the  process  group 
and  management  for  completeness  and  approval 


Satisfy  all 
training 
requirements 


Team  Member 
Training  Log 
Form  LOGTRNM 


Notify  team 
members  of 
any 

unsatisfied 

training 

requirement 


> 
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Decision  Analysis  and  Resolution 


Team  Member  or 
Team 


Decision  Owner 


Decision 

Participants 


Decision 

Stakeholders 


Process  Manager 


An  important 
decision  needed 
in  which  there  is 
more  than  one 
solution. 


The  DAR  process  can  be 
initiated  anytime  (i.e  prior  to 
a  launch,  during  a  launch  or 
re-launch  or  during  project 
plan  execution).  During  a 
launch,  or  re-launch,  DAR 
is  planned  for,  not  actually 
executed  during  the  launch 
or  re-launch. 


Decision  Owner  is  ultimately 
responsible  for  making  the 
final  decision 


Decision  Participants  have 
the  knowledge  and 
background  required  to 
assist  in  evaluating  the 
alternative  solutions  and 
making  an  informed  decisiorl 


Includes: 


-Defining  issue  to  be 
addressed 

-Reviewing  issue  with 
participants  and 
stakeholders 
-Identifying  Alternative  j 
Solutions 

-  Determine  Evaluation 

Criteria 

-  Determine  Evaluation 

Methods 
-Collect  Data 

-  Evaluate  Alternatives 

-  Select  Solution 


Decision  Analysis 
and 

Resolution  Form 
Form  DAR 
(Complete  form. 
Sign  and  send 
Process  Manager) 


Rework 


Includes: 
-Reviewing  issue 
-Identifying  Alternative 
Solutions 

-  Determine  Evaluation 

Criteria 

-  Determine  Evaluation 

Methods 
-Collect  Data 

-  Evaluate  Alternatives 


Decision  Stakeholders  are 
anyone  that  is  affected  by 
the  decision  but  does  not 
participate  in  the  decision 
making  process. 


Included: 

-Reviewing  Issue 

-  Reviewing  alternative 
solutions,  evaluation  criteric 
and  associated  factors,  anc 
selected  evaluation  method: 

-  Reviewing  evaluation 
results  and  selected  solutior 


Decision  Analysis 
and 

Resolution  Form 
Form  DAR 
(Sign  and 
configure  DAR 
data  package) 
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Appendix  B:  TSP+  Scripts  for  Process  Operation  and  Team 
Operations 


The  high-level  scripts  guiding  the  process  team  and  the  other  development  teams  in  an  organization 
are  included  here  to  aid  TSP  coaches  and  TSP-trained  process  groups  to  understand  their  roles  in  the 
overall  AIM  implementation  process. 
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TSP+  Process  Operations — Script  POPS 


Purpose 

-  To  guide  an  organization  in  improving  its  software  performance 

-  To  couple  the  TSP,  CMMI,  and  Lean  Six  Sigma  improvement  initiatives 

Entry  Criteria 

Management  seeks  to  improve  the  performance  of  its  software-related  operations. 

General 

This  script  assumes  a  TSP/CMMI  implementation.  The  use  of  Lean  Six  Sigma  methods 
and  tools  is  optional. 

Step 

Activities 

Description 

1 

Contact 

-  Determine  how  the  TSP  and  CMMI  can  address  management’s  concerns. 

-  Talk  with  working  level  engineers  and  managers  to  build  interest. 

2 

Awareness 

-  Expose  senior  management  to  the  opportunity. 

-  Describe  the  potential  benefits  and  the  operating  level  interest. 

-  Provide  credible  references. 

3 

Obtain 

Sponsorship 

-  Hold  a  one-day  executive  seminar  for  the  senior  managers  and  executives,  which 
include  a  CMMI  overview. 

-  Hold  a  half-day  planning  workshop  to  identify  initial  areas  for  TSP  trial  use 

-  Identify  a  manager  to  be  responsible  for  the  transition  plan  and  execution. 

4 

Develop  Transition 
Plan 

The  responsible  manager  produces  a  plan  for  TSP  trial  use. 

-  arranges  for  qualified  training  and  coaching  support 

-  schedules  managers  and  team  members  for  training 

-  schedules  initial  TSP  launches,  checkpoints,  and  relaunches 

5 

TSP  Trial  Use 

The  organization  conducts  trial  TSP  projects  (TOPS  script). 

-  trains  the  engineers  and  managers 

-  launches  the  teams  and  regularly  reviews  performance 

-  identifies  internal  candidates  to  be  initial  PSP  instructors  and  TSP  coaches 

6 

Evaluation 

The  organization  assesses  team  and  TSP  performance  and  decides  to  proceed  with  the 

process  improvement  initiative. 

-  identifies  a  manager  to  lead  the  long-term  improvement  effort  and  become  the 
process  group  team  lead 

-  allocates  initial  resources 

-  issues  a  policy  describing  the  process  improvement  initiative  and  its  importance  to  the 
business 

-  defines  management  responsibilities 

7 

Adoption:  Process 
Group  Formation 

The  process  group  team  lead,  with  the  help  of  the  TSP  Coach  (POPS7  script) 

-  produces  a  process  improvement  plan  proposal 

-  reviews  this  plan  proposal  with  management  and  gets  their  approval 

-  recruits  a  staff  and  trains  that  staff  in  CMMI,  PSP,  and  TSP 

-  launches  the  process  group  team  to  plan  and  execute  the  process  improvement  plan 
proposal 

8 

Adoption: 

Institutionalize  TSP 

Working  with  project  management,  the  process  manager 

-  develops  a  TSP  introduction  plan  and  schedule  for  each  project  team 

-  assists  projects  in  launching  and  running  TSP  projects  (TOPS  script) 

9 

Continuing 

Improvement 

Using  the  project’s  needs  as  a  guide  and  reviewing  the  Process  Group  Roles  and 
Responsibilities  specification,  set  priorities  and  build  and  execute  a  plan  (script  CYCLE) 
based  on  organizational  business  objectives  for 

-  defining  team  and  organizational  processes 

-  establishing  and  maintaining  a  process  asset  library 
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-  providing  continuing  training  and  coaching  guidance 

-  obtaining  needed  tools  and  methods 

-  providing  tool  and  method  training  and  support 

-  assessing  the  organization  annually  to  identify  further  improvement  needs 

Apply  Lean  Six  Sigma  methods  and  tools  to  improve  current  process  performance. 

Continuing  Review 

Management  annually  reviews  the  organization’s  software  operations. 

-  analyzes  cost  and  benefit  data 

-  obtains  customer,  manager,  and  engineer  feedback  on  improvement  results 

adjusts  the  improvement  program  to  address  identified  problems  and  capitalize  on  new 
improvement  opportunities  during  Meeting  1  of  the  process  group’s  (re)launches  (script 
CYCLE) 
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TSP+  Process  Group  Formation — Script  POPS7 


Purpose 

To  guide  the  process  group  (PG)  team  lead  in  planning  for  and  staffing  a  process 
improvement  group 

Entry  Criteria 

-  The  organization  has  initiated  a  software  process  improvement  program. 

-  Management  has  issued  a  process  improvement  policy  statement  and  named  a 
responsible  manager. 

-  Initial  process  improvement  resources  have  been  allocated. 

Step 

Activities 

Description 

1 

Define 

Responsibilities 

The  PG  team  lead,  with  help  from  the  TSP  Coach 

-  documents  the  principal  responsibilities  of  the  job  and  proposed  group  (specification 
Process  Group  (PG)  Roles  and  Responsibilities) 

-  reviews  PG  roles  and  responsibilities  with  existing  staff  groups  (configuration 
management,  quality  assurance,  and  test  for  example) 

-  reviews  PG  roles  and  responsibilities  with  development  department  managers 

-  revises  PG  roles  and  responsibilities  based  on  the  review  results 

-  reviews  PG  roles  and  responsibilities  with  senior  management  for  approval 

2 

Develop 

Improvement  Plan 

The  TSP  Coach  works  with  the  PG  team  lead  in  developing  a  proposal  for  the  process 
improvement  work. 

-  tasks  to  be  performed 

-  training,  support,  and  assistance  to  be  provided 

-  resources  needed,  both  full  and  part  time 

-  proposed  recruiting  schedule 

-  proposed  task  schedule 

3 

Obtain  Plan 

Approval 

The  PG  team  lead 

-  reviews  the  proposal  with  existing  staff  groups  (configuration  management,  quality 
assurance,  and  test  for  example) 

-  reviews  the  proposal  with  development  department  managers 

-  obtains  agreement  from  the  development  and  staff  groups  to  provide  the  needed  part 
time  process  improvement  resources 

-  revises  the  proposal  based  on  the  review  results 

-  reviews  the  proposal  with  senior  management  for  approval 

4 

Recruit  Initial  Staff 

The  PG  team  lead  recruits  the  process  staff. 

-  obtains  a  core  staff  of  process  experts  (trained  and  experienced  if  possible) 

-  utilizes  part-time  support  from  the  development  groups  where  planned 

-  recruits  experienced  professionals  from  internal  development  groups  where  possible 

-  maintains  a  mix  of  engineering,  process,  technology,  and  management  skills 

5 

Train  Initial  Staff 

Using  internal  skills  where  possible,  the  PG  team  lead  trains  the  process  staff  in  the  key 
process  improvement  technologies. 

-  the  Capability  Maturity  Model  (CMMI,  P-CMM,  and  so  forth) 

-  the  Personal  Software  Process  (PSP) 

-  the  Team  Software  Process  (TSP) 

-  Lean  Six  Sigma  methods  and  tools  for  subsequent  improvement  analysis 

-  the  principal  tools  and  methods  used  in  the  organization 

6 

Process  Group 

Team  Launch 

The  process  group  launches  in  order  to  plan  and  execute  the  approved  process 
improvement  proposal  (script  LAU). 

Exit  Criteria 

The  PG  has  successfully  launched. 
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TSP+  Team  Operations — Script  TOPS 


Purpose 

To  guide  managers,  teams,  and  engineers  in  introducing  and  using  the  TSP  process. 

Entry  Criteria — Trial  Use 

-  Senior  management  has  participated  in  the  TSP  executive  strategy  seminar  and 
planning  workshop  and  supports  TSP  introduction. 

-  An  initial  TSP  trial  program  has  been  approved. 

Entry  Criteria — TSP 

Adoption 

To  move  beyond  trial  use  and  start  broad  TSP  introduction 

-  TSP  trial  use  has  been  successful. 

-  A  TSP  adoption  plan  has  been  developed  and  approved. 

-  Initial  PSP  instructors  and  TSP  coaches  have  been  selected  and  are  scheduled  for 
training. 

Entry  Criteria — TSPm  Initial 
Use 

To  launch  a  TSPm  multi-team  or  distributed  multi-team 

-  TSP  trial  use  has  been  successful. 

-  The  organization  has  at  least  one  authorized  TSP  coach  on  its  staff  and  enough 
additional  coaches  are  to  be  trained  to  support  team  operation. 

General 

To  use  the  TOPS  script,  one  or  more  of  the  entry  criteria  must  be  satisfied. 

Step  Activities 

Description 

1  Team  Formation 

and  Training 

For  each  TSP  or  TSPm  team,  a  project  is  identified  and  the  staff  has  been  trained. 

-  All  managers  on  each  project  or  in  its  management  chain  are  TSP  trained  before  the 
launch. 

-  All  project  software  professionals  are  PSP  trained  before  the  launch. 

-  All  other  project  professionals  are  trained  in  the  personal  process  before  the  launch. 

2  Launch  Preparation 

-  Prepare  to  launch  each  TSP  or  TSPm  team  (checklist  PREPL). 

-  For  each  TSPm  multi-team  or  distributed  multi-team,  also  follow  scripts  PREP  and 
PREPW  during  launch  preparation. 

3  TSP  Cycle 

Follow  script  CYCLE  until  project  conclusion  in  order  to  guide  the  team  in: 

-  launching  the  project 

-  executing  the  team’s  detailed  planning 

-  undergoing  a  checkpoint  (script  CFIECKPOINT) 

-  conducting  a  phase,  cycle,  or  project  postmortem 

-  preparing  for  subsequent  relaunches  (if  needed) 

4  Multi-Team  (TSPm) 

Project  Operations 

For  multi-teams  only,  follow  script  TOPS4  concurrently  for  each  sub-team  following  the 
TSP  cycle  (script  CYCLE)  in  order  to  manage  the  sub-team  interdependencies  and 
overall  project. 

Exit  Criteria 

-  Project  completed  with  team  and  team  member  plan  and  actual  data 

-  Project  data  filed  in  the  project  notebook  (specification  NOTEBOOK) 

-  Final  project  report  prepared  and  presented  to  management 
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TSP+  Project  Operations — Script  TOPS4 


Purpose 

To  guide  managers,  team  leaders  and  team  members  in  managing  a  TSPm  project 

Entry  Criteria 

The  project  has  completed  a  launch  or  relaunch. 

Step 

Activities 

Description 

1 

The  Leadership 

Team  Launch 

Following  the  project  (re)launch  and  under  the  guidance  of  a  qualified  TSP  coach,  the 
leadership  team  holds  a  one-day  launch  (script  LTL). 

-  reviews  the  organization’s  and  this  project’s  goals 

-  develops  the  leadership  team’s  management  strategy 

-  defines  the  role  manager  teams’  goals  and  responsibilities 

-  allocates  tasks  and  responsibilities  among  the  leadership  team  members 

2 

Leadership  Team 
Operations 

Following  the  leadership  team  launch,  the  leadership  team 

-  manages  the  project  and  each  sub-team  in  performing  its  work 

-  holds  weekly  meetings  to  review  project  status  and  issues  (script  WEEKL) 

-  provides  guidance  to  the  role  manager  team  launches  (script  RTL) 

-  meets  at  least  monthly  with  each  role  manager  team  (script  WEEKLR) 

-  regularly  reports  to  senior  management  and  the  customer  on  project  status  and 
progress  (specification  STATUS) 

3 

Sub-team 

Operations 

Following  the  team  and  sub-team  (re)launches,  each  sub-team  follows  its  defined 
process  and  detailed  plan  in  doing  its  work. 

4 

Role  Manager 

Team  Launches 

Soon  after  the  team  (re)launch  and  under  the  guidance  of  a  TSP  coach,  each  role 
manager  team  holds  a  two-day  launch  (script  RTL). 

-  the  leadership  team  defines  its  goals  for  the  role  manager  team 

-  the  role  managers  establish  their  strategy  and  plan  to  meet  these  goals 

-  the  role  managers  allocate  tasks  and  responsibilities  among  team  members 

-  the  role  managers  prepare  and  review  their  plan  with  the  leadership  team 

5 

Quarterly  or 

Monthly 

Management 

Reviews 

The  leadership  team  and  senior  management  periodically 

-  review  project  status,  progress,  and  projections 

-  assess  the  team  for  quality  level  performance 

-  assess  the  team  for  expert  level  performance 

-  identify  issues  and  problems  and  assign  responsibilities 

6 

Periodic  Customer 
Reviews 

The  leadership  team  regularly  reviews  status  and  progress  with  the  customer. 

-  planned  versus  actual  performance 

-  outstanding  issues  and  problems,  actions  planned,  and  assistance  needed 

Exit  Criteria 

-  Project  or  project  phase  completed  with  team  and  team  member  plan  and  actual  data 
filed  in  the  project  notebook  (specification  NOTEBOOK). 

-  Final  project  report  prepared  and  presented  to  management 
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TSP  Cycle— Script  CYCLE 

Purpose 

-  To  guide  teams  through  the  use  of  a  defined  and  structured  process,  with  repeatable 
and  measurable  steps,  which  provides  rapid  feedback  on  the  quality  of  the  product 
and  progress  towards  completion 

-  To  guide  teams  in  the  establishment  of  a  shared  understanding  of  the  work  and  how  it 
is  to  be  done,  which  includes  a  common  understanding  of  the  team  goals,  team 
member  roles,  product  or  components  to  be  produced,  available  resources  and 
existing  constraints,  and  measures  of  success. 

-  To  provide  the  mechanisms  required  in  order  for  a  team  to  practice  self-management 

Entry  Criteria 

-  All  team  members  have  been  adequately  trained  in  the  use  of  PSP  and  TSP. 

-  All  team  members  and  the  team  leaders  have  been  identified  and  allocated  to  the 
project. 

-  A  qualified  TSP  coach  is  available  to  guide  and  coach  the  team  through  the  TSP 

Cycle. 

General 

-  Depending  on  the  size  and  needs  of  the  project,  a  TSP  Cycle  can  range  from  a  period 
of  a  few  weeks  to  a  few  months. 

-  Depending  on  a  project’s  overall  duration  and  needs,  the  team  may  choose  to  use 
phases,  cycles,  or  both  in  determining  when  it  needs  to  conduct  a  (re)launch.  A  phase 
represents  a  part  of  the  development  lifecycle  such  as  the  implementation  phase,  and 
a  cycle  represents  the  time  between  planning  horizons.  A  phase  can  encompass 
several  cycles,  just  as  a  cycle  can  encompass  several  phases. 

Step 

Activities 

Description 

1 

Team  (Re)Launch 
(LAU/LAUm  or 
REL/RELm) 

-  During  the  launch,  the  team  learns  from  management  what  it  is  supposed  to  do, 
makes  a  plan  for  doing  the  desired  work,  and  then  reviews  the  plan  with  management. 
The  two  desired  outcomes  of  the  launch  are  an  approved  team  plan  for  producing  a 
particular  product,  both  the  overall  project  plan  and  a  detailed  next  phase  plan,  and  a 
jelled  self-directed  team. 

-  During  a  relaunch  (script  REL  or  RELm),  the  team  members  update  their  overall  plan 
and  develop  a  new  next-phase  plan  based  on  what  they  have  done  since  the  initial 
launch  or  the  prior  relaunch.  The  team  has  already  committed  to  management  what  it 
intends  to  do  and,  if  that  commitment  is  unchanged,  the  members  do  not  need  to 
repeat  the  management  meetings.  However,  if  the  project  has  changed  in  any 
significant  way  (such  as  changes  to  the  product  requirements,  the  team  membership, 
project  schedule,  project  scope,  etc.),  then  the  relaunch  should  be  regarded  as  a  new 
project  launch  and  all  of  the  meetings  (script  LAU  or  LAUm)  and  activities  should  be 
held. 

2 

Plan  Execution 

-  The  team  executes  the  cycle  plan  created  during  the  (re)launch,  making  updates  or 
changes  to  the  plan  as  necessary. 

-  The  team  uses  scripts  DEV  and  MAINT  to  guide  the  team  in  developing,  maintaining, 
and  enhancing  software-intensive  products. 

-  The  team  meets  weekly  (script  WEEK)  to  ensure  that  all  team  members  understand 
current  project  status  and  know  what  to  do  next. 

-  The  team  leader  conducts  periodic  management  and  customer  status  meetings  (script 
STATUS). 

Checkpoint 

About  a  month  into  the  TSP  cycle  or  halfway  through  the  cycle,  whichever  is  shorter,  the 
TSP  Coach  leads  the  team  through  a  checkpoint  (scripts  CHECKPOINT). 

3 

Cycle  or  Project 
Postmortem 

-  The  cycle  postmortem  is  held  before  any  subsequent  launch  or  relaunch  and  includes 
only  the  data  on  the  work  completed  during  the  earlier  project  phases  or  cycles.  The 
focus  of  these  postmortems  is  to  evaluate  interim  project  status  and  calibrate  planning 
parameters  to  revise  goals  and  improve  performance  in  subsequent  cycles  (see  script 
PM). 

-  The  project  postmortem  is  conducted  at  the  end  of  the  project  and  includes  the  full 
product  or  project  data.  Organizational  process  baseline  data  may  be  updated  at  this 
time  (see  script  PM). 

CMU/SEI-2010-SR-032  |  51 


Exit  Criteria 


-  A  completed  high-quality  product 


-  A  project  summary  report  (see  specification  SUMMARY) 


-  PIPs  for  all  identified  process  improvements 
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Appendix  C:  Goal-Question-(lndicator)-Metric  Examples 


The  following  GQ(I)M  templates  are  in  no  sense  the  minimum  necessary  to  fully  understand  and 
implement  measurement  under  AIM.  They  are  simply  included  here  as  examples  of  what  can  be  done. 
The  first  indicator  is  for  TSP-style  earned  value  management,  while  the  second  one  gives  a  more 
traditional  view  of  earned  value  at  the  organization  level.  A  reasonably  complete  set  of  indicators 
would  likely  include  indicators  for  time-on-task,  planned  vs.  actual  quality  in  several  dimensions,  and 
the  TSP  Quality  Profile  Indicator. 
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Date:  6-Sep-2005 


Indicator  Name/Title:  Earned  Value 

OBJECTIVE 

QUESTIONS 

VISUAL  DISPLAY 


To  determine  current  schedule  status  of  a  project  and  to 
estimate  a  likely  completion  date. 

Where  is  the  project  with  respect  to  its  current  and  original 
schedule?  When  is  the  project  likely  to  finish? 


Cumulative  Earned  Value 


Weeks 


— ♦ — Cumulative  Planned  Value 
— * — Cumulative  EV 
— * — Cumulative  Predicted  Earned  Value 
— • — Baseline  Cumulative  Plan  Value 


PERSPECTIVE 

Project  team 
Team  leader 


Project  manager 
Program  manager 
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Inputs 


Data  Elements 

List  all  the  data  elements  in  the  production  of  the 
indicator. 

Estimated  task  duration  (hours) 

Estimated  hours  available  each  week  (hours) 

Estimated  task  completion  date  (week) 

Actual  task  duration  (hours) 

Actual  hours  worked  each  week  (hours) 

Actual  task  completion  date  (week) 

DATA  COLLECTION 
How 

When/How  Often 
By  Whom 
Forms 

DATA  REPORTING 
Responsibility  for  Reporting 


Definition 

Precisely  define  the  data  element  used  or  point  to  where  the  definition  can 
be  found. 


By/To  Whom 

How  Often 

DATA  STORAGE 

Where 

How 

Security 


Manual 

As  defined  tasks  begin  and  end/contemporaneous 

Individual  developers 

Personal  time  log 
Personal  task  list 

Team  members 
Team  plan  manager 
Team  leader 
Project  manager 

By  project  team  to  team  leader 
By  team  leader  to  project  manager 
By  project  manager  to  program  manager 

Weekly 

Team  project  data  folder  (virtual  project  notebook) 

Network  save  with  automatic  backups 

Only  team  leader,  team  members,  and  appropriate  IT 
personnel  have  access  to  raw  data 
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ALGORITHM 

Individual  earned  values  computer  as: 

[estimated  EV  per  task]  =  [estimated  time  per  task]  /  sum  of 
([estimated  time  per  task]  of  all  tasks) 

[actual  EV  per  task]  =  [estimated  EV  per  task] 

[weekly  estimated  EV]  =  sum  of  ([estimated  EV  per  task]  of  all 
tasks  estimated  to  finish  that  week) 

[weekly  actual  EV]  =  sum  of  ([actual  EV  per  task]  of  all  tasks 
actually  finished  that  week) 

ASSUMPTION 

None 

ANALYSIS 

Calculation  of  how  many  weeks  ahead  or  behind  schedule 
the  project  is 

Calculation  of  how  many  weeks  likely  remain  until  the  project 

finishes 

Helps  to  determine  if  the  project  should  be  replanned  or 

relaunched 

INTERPRETATION 

Compare  current  plan  and  projected  EV  track  to  baselined  EV 
projection  (included  on  chart). 

Compare  to  similar  finished  projects  in  the  database. 

PROBING  QUESTIONS 

When  did  the  team  launch?  Relaunch?  Replan? 

Why  did  the  baseline  change?  (Change  in  scope,  poor 
estimates  for  size  or  hours  available,  poor  estimates  for 
productivity,  change  in  team  size) 

EVOLUTION 

Add  ‘guard  bands’  to  projected  EV  line  showing  earliest  and 
latest  dates  possible  given  the  raw  data. 

FEEDBACK  GUIDELINES 


X-REFERENCES 

Time  on  task 

Time  distribution  profile 

Defect  distribution  profile 
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Indicator  Name/Title:  Earned  Value  Management  (Cost  and  Schedule) 


Date:  6-Sep-2005 


OBJECTIVE 


QUESTIONS 
VISUAL  DISPLAY 


To  monitor  contract  performance  for  contracts  that  use  Earned  Value 
Management  (EVM).  This  indicator  will  track  the  Cost  Performance  Index 
(CPI)  and  the  Schedule  Performance  Index  (SPI)  in  relation  to  the  target 
values. 

Are  the  CPI  and  the  SPI  within  their  target  areas? 


Earned  Value  Management 


Where 


Green 

CPI  >1.0 

and 

SPI  >  1.0 

Yellow 

CPI  <  1.0 

or 

SPI  <  1.0 

Red 

CPI  <0.9 

or 

SPI  <0.9 

Target  Area 

CPI  =  0.95  to  1.08 
SPI  =  0.95  to  1.08 
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PERSPECTIVE 


Project  manager 


INPUTS 

Data  Elements  Definition 

List  all  the  data  elements  in  the  production  of  the  Precisely  define  the  data  element  used  or  point  to  where  the 
indicator.  definition  can  be  found. 

CPI  =  BCWP  /  ACWP  _ 

(BCWP:  Budget  Cost  of  Work  Performed)  _ 

(ACWP:  Actual  Cost  of  Work  Performed)  _ 

SPI  =  BCWP  /  BCWS  _ 

(BCWP:  Budget  Cost  of  Work  Performed)  _ 

(ACWP:  Budget  Cost  of  Work  Scheduled) 

DATA  COLLECTION 

How 

When/How  Often 
By  Whom 
Forms 


? 

As  defined  work  begins  and  ends  /  contemporaneous 

Specify  who  will  collect  the  data  (an  individual,  office,  etc.). 

Reference  any  standard  forms  for  data  collection  (if  applicable)  and 
provide  information  about  where  to  obtain  them. 


DATA  REPORTING 


Responsibility  for  Reporting 


Indicate  who  has  responsibility  for  reporting  this  data. 


By/To  Whom  Indicate  who  will  do  the  reporting  and  to  whom  the  report  is  going  to. 

This  may  be  an  individual  or  an  organizational  entity. 

How  Often  Specify  how  often  the  data  will  be  reported  (daily,  weekly,  monthly,  as 

required,  etc.). 

DATA  STORAGE 

Where  Indicate  where  the  data  is  to  be  stored. 


How 


Indicate  the  storage  media,  procedures,  and  tools  for  configuration 
control. 


Security 

ALGORITHM 


ASSUMPTION 


Specify  how  access  to  this  data  will  be  controlled. 

Specify  the  algorithm  or  formula  required  to  combine  data  elements  to 
create  input  values  for  the  indicator.  It  may  be  very  simple,  such  as 
Input1/lnput2,  or  it  may  be  much  more  complex.  It  should  also  include 
how  the  data  is  plotted  on  the  graph. 

Identify  any  assumptions  about  the  organization,  its  processes,  life-cycle 
models,  and  so  on,  that  are  important  conditions  for  collecting  and  using 
this  indicator. 
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ANALYSIS 

Specify  what  type  of  analysis  can  be  done  with  the  information. 

INTERPRETATION 

Describe  what  different  values  of  the  indicator  mean.  Make  it  clear  how 

the  indicator  answers  the  “Questions”  sections  above.  Provide  any 
important  cautions  about  how  the  data  could  be  misinterpreted  and 
measures  to  take  to  avoid  misinterpretation. 

PROBING  QUESTIONS 

List  questions  that  delve  into  the  possible  reasons  for  the  value  of  an 
indicator,  whether  performance  is  meeting  expectations  or  whether 
appropriate  action  is  being  taken. 

EVOLUTION 

Specify  how  the  indicator  can  be  improved  over  time,  especially  as  more 
historical  data  accumulates  (e.g.,  by  comparison  of  projects  using  new 
processes,  tools,  environments  with  a  baseline;  using  baseline  data  to 
establish  control  limits  around  some  anticipated  value  based  on  project 
characteristics). 

FEEDBACK  GUIDELINES 

A  description  of  the  procedure  to  use  when  recommending  modification 
to  the  indicator  template. 

X-REFERENCES 

If  the  values  of  other  indicators  influence  the  appropriate  interpretation  of 
the  current  indicator,  refer  to  them  here. 
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Appendix  D:  Process  Improvement  Proposals  (PIPs) 


PIPs  Requesting  Changes  to  “Classic”  TSP 

As  part  of  the  original  effort  to  identify  gaps  in  a  previous  version  of  TSP,  Process  Improvement 
Proposals  (PIPs),  a  standard  process  element  in  TSP,  were  used  to  capture  areas  for  potential 
improvements.  These  PIPs  are  included  here  mainly  for  the  benefit  of  those  organizations  that  already 
have  significant  TSP  implementation  in  place  and  wish  to  use  AIM  concepts  in  a  more  formal  CMMI 
implementation  (UC2  noted  above). 

Note  that  not  all  suggestions  to  change  TSP  were  implemented  in  the  way  suggested  by  the  PIP,  or 
even  acted  upon  in  a  way  that  implements  a  new  or  modified  process  element  that  would  fill  the  gap. 
For  example,  the  ENGR-X  PIPs  did  not  generate  massive  changes  and  additions  to  TSP  process 
elements  because  the  general  philosophy  of  TSP  is  to  be  non-directive  as  to  which  development 
methods  are  used.  The  ENGR-X  PIPs  are  addressed  in  part,  as  suggested  in  ENGR-3,  by  this 
document,  as  well  as  by  many  specific  but  relatively  straightforward  modifications  and  additions  in 
TSP+  that  reflect  the  advice  of  experienced  TSP  coaches. 


PIP# 

Filename 

Candidate  Modified  (new)  TSP  Process  Elements 

ALL-1 

PIP  ALL-1  .doc 

Policy  guidance  (new) 

ALL-2 

PIP  ALL-2.doc 

TSP  Checkpoint  Scripts/Forms  (new) 

ALL-3 

PIP  ALL-3.doc 

TSP  REVIEW  Checklist  (new— from  TSP-MT) 

CM-1 

PIP  CM-1.doc 

PREPL/PREPR,  LAUPM 

ENGR-1 

PIP  ENGR-1.doc 

Templates  (new)  for  Software  Requirements  Specification  (SRS), 
Engineering  Requirements  Specification  (ERS),  Software  Design 
Specification  (SDS) 

ENGR-2 

PIP  ENGR-2.doc 

Interfaces  in  CMMI;  potentially  effects  scripts  REQ/ANA,  HLD,  IMP; 
specifications  for  Customer  Interface,  Design,  Implementation,  and  Test 
role  managers 

ENGR-3 

PIP  ENGR-3.doc 

TSP-CMMI  implementation  guide  (new),  potential  minor  changes  to 
engineering  scripts  and  role  manager  specifications 

IPM-1 

PIP  IPM-1.doc 

LAU4 

IPM-2 

PIP  IPM-2.doc 

LAU3,  possibly  LAU4/LAU6 

MA-1 

PIP  MA-1.doc 

GQIM  Indicator  Templates  (new)  or  something  else 

OPD-1 

PIP  OPD-1.doc 

Organization  Process  Notebook  (new,  includes  all  TSP  process  assets, 
plus  additions  from  PSP/TSP  books  and  extensions,  plus  local  additions) 
and  its  use  in  LAU3  (modified) 

OPD-2 

PIP  OPD-2.  doc 

Tailoring  guidelines  (new)  and  their  use  in  LAU3  (modified) 

OPD-3 

PIP  OPD-3.doc 

Standard  PM  data  specification  (new)  appropriate  for  use  in  future 
planning  and  for  inclusion  in  an  organization’s  measurement  repository 

OPF-1 

PIP  OPF-1.doc 

TSP-CMMI  Accelerated  Introduction  Method  definition  (modified  based 
on  the  existing  TSP  Introduction  Method) 

OPF-2 

PIP  OPF-2.doc 

POPS,  POPS7,  and  POPS9  (modified,  from  TSP-MT)  possibly  in 
conjunction  with  other  TSP  process  assets  tailored  specifically  to  train, 
launch,  and  execute  EPG  functions 

OT-1 

PIP  OT-1.doc 

PSP/TSP  training  sequence  (modifies  what  is  currently  part  of  the  TSP 
Introduction  Strategy) 

PMC-1 

PIP  PMC-1.doc 

LAU8 

PP-1 

PIP  PP-1.doc 

PREPL/PREPR 
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PIP# 

Filename 

Candidate  Modified  (new)  TSP  Process  Elements 

PP-2 

PIP  PP-2.doc 

LAU3 

PP-3 

PIP  PP-3.doc 

Stakeholders  PIP — potentially  affects  PREPL/PREPR,  LAU3,  LAU8, 
roles,  WEEK,  stakeholder  matrix  (new) 

Process  review 

PIP  Process  Review.doc 

Remove  references  to  Process  Review  Meetings. 

QA-1 

PIP  QA-1.doc 

TSP  QA  Plan  (new) 

REQ-1 

PIP  REQM-1.doc 

REQ,  ANA,  SUMS,  TASK,  or  new  guidance 

RSKM-1 

PIP  RSKM-1  .doc 

LAU7 

ROLE-1 

PIP  ROLE-1  .doc 

Team  role  descriptions 

CMU/SEI-2010-SR-032  |  61 


TSP  Process  Improvement  Proposal — Form  PIP 


Name 

Noopur  Davis  /  James  McHale 

Date 

3/20/2008 

e-mail 

nd(a)sei. cmu.edu  /  idm(a)sei. cmu.edu 

Organization 

SEI 

Project 

TSP  Initiative 

Launch/Phase 

Project  Mgmt. 

— ML2/3 

PIP  Number 

ALL-1 

Priority 

High 

Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 


Ref.  all  PAs  GP2.1  TSP  should  include  policy  guidelines/templates/samples  that  state  that  projects  follow  the  TSP  and 
other  process  assets  as  defined  in  the  OSSP.  These  policies  should  be  specifically  tailored  to  the  organization  as  part  of 
broad  transition,  after  piloting,  to  reflect  the  pilot  project  transition  experience. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 
New  process  element(s)  needed. 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time _  Reduced  Risk _ 

Describe  the  likely  benefits  of  the  suggested  change. 

As  organizations  start  adopting  the  TSP  across  the  board,  policies  about  its  use  would  enforce  the  organization’s 
commitment,  and  will  also  contribute  to  “that  is  how  we  do  things  here.”  Would  also  increase  CMMI  conformance. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 


Name 

James  McHale 

Date  3/20/08 

e-mail 

idm@sei.cmu.edu 

Organization 

SEI 

Project 

TSP  AIM 

Launch/Phase 

Project  Mgmt — ML3 

PIP  Number 

ALL-2 

Priority 

High 

Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 


Ref.  all  PAs  GP2.9.  Make  the  TSP  Checkpoint  Process  assets  part  of  the  standard  TSP  download  (i.e.,  available  to  all 
TSP  coaches)  in  order  to  address  GP2.9  which  states  “Objectively  evaluate  adherence  of  the  <x>  process  against  its 
process  description,  standards,  and  procedures,  and  address  noncompliance.”  This  is  a  fairly  good  partial  description  of 
the  TSP  coach  role. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 

Add  TSP  Checkpoint  Process  to  standard  TSP  package.  Probably  not  a  complete  solution  to  the  general  QA  issue  but 
this  is  a  process  asset  that  should  be  generally  available  for  partners  and  coaches,  especially  as  many  coaches  push 
specific  elements  of  a  checkpoint  down  to  team  roles,  e.g.,  process  and  quality  managers. 


Improvement  Benefits  (check  one) 

Improved  Quality _  Reduced  Cycle  Time _  Reduced  Risk _ X 

Describe  the  likely  benefits  of  the  suggested  change. 

Standardize  TSP  Checkpoints  and  improve  CMMI  conformance. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 

Name  James  McHale  /  Gene  Miluk _  Date  7-May-08 

e-mail  jdm@sei.cmu.edu  /  gem@sei.cmu.edu _  Organization  SEI _ 

Project  TSP-CMMI  AIM _  Launch/Phase  CMMI  ML2/3 _ 


PIP  Number  ALL-3 _  Priority  High 


Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 

Ref.  GP  2.10 — “Review  the  activities,  status,  and  results  of  the  <X>  process  with  higher  level  management  and  resolve 
issues.”  Bring  the  Quarterly  Review  Checklist  in  Winning  With  Software  Appendix  D  (a  version  of  this  already  exists  in 
TSP  for  Multi-Teams  as  'Checklist  REVIEW.doc’)  into  the  standard  TSP  distribution). _ 

Note:  This  should  work  well  in  conjunction  with  PSP  OPF-2,  running  the  EPG  as  a  TSP  team. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 
Quarterly  Review  Checklist  (see  'Checklist  REVIEW.doc’  in  TSP-MT). 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time  X  Reduced  Risk  X 

Describe  the  likely  benefits  of  the  suggested  change. 

Under  existing  TSP  Introduction  activities,  management  does  not  necessarily  receive  any  overview  of  the  process 
improvement  effort  as  a  whole.  The  intent  is  to  give  management  a  comprehensive  review  of  product,  process,  and 
improvement  concerns,  which  should  improve  the  quality  of  the  implementation,  reduce  risk  in  general,  and  drive  a 
quicker  implementation. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 


Name 

James  McHale 

Date 

3/6/08 

e-mail 

idm@sei.cmu.edu 

Organization 

SEI 

Project 

TSP  AIM 

Launch/Phase 

Project  Mgmt. 

— ML2/3 

PIP  Number 

CM-1 

Priority 

High 

Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 


Ref.  GP  2.6  and  GP  3.2  (PP,  PMC,  IPM,  RSKM  PAs),  IPM  SP  1.6 — Call  out  project  management  artifacts  separately  in  a 
standard  TSP  configuration  management  plan  (to  be  defined).  Include  the  aspects  of  project  data  management  (e.g., 
project  NOTEBOOK).  Provide  for  capture  of  new  and  tailored  project  processes  and  data  as  organizational  process 
assets). 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 

Possibly  PREPL/PREPR  checklists  (e.g.,  to  create  an  online  project  NOTEBOOK),  LAUPM  (to  populate  the  NOTEBOOK 
initially),  script  WEEK  (to  store/manage  weekly  data  ‘appropriately’),  script  PM  (to  store  project  summary  data).  Add 
script  SCM  and  other  process  assets  from  Introduction  to  Team  Software  Process,  App.  B  to  the  standard  TSP  release. 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time _  Reduced  Risk  X _ 

Describe  the  likely  benefits  of  the  suggested  change. 

Improve  consistency  in  actually  keeping  the  project  NOTEBOOK  data  (in  whatever  form  it  may  take)  up  to  date,  reduce 
the  risk  that  something  is  inadvertently  omitted  from  it,  and  improve  CMMI  conformance.  For  project  process  assets  not 
captured  above  (e.g.,  PIPs,  new  and  tailored  project  processes),  some  level  of  configuration  management  must  be 
maintained  for  project  use,  and  this  should  facilitate  submission  into  the  organization  process  asset  library. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 

Name  James  McHale  /  Gene  Miluk _  Date  17-Jun-08 

e-mail  jdm@sei.cmu.edu  /  gem@sei.cmu.edu _  Organization  SEI _ 

Project  TSP-CMM1  AIM _  Launch/Phase  Engineering  PAs _ 


PIP  Number  ENGR-1 _  Priority  High 


Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 

REQM  SP1.3 — “Manage  changes  to  the  requirements  as  they  evolve  during  the  project." _ 

REQM  SP1.4 — “Maintain  bi-directional  traceability  among  the  requirements  and  work  products." _ 

REQM  SP1.5 — “Identify  inconsistencies  between  the  project  plans  and  work  products  and  the  requirements.” _ 

Traceability  is  specified  through  several  scripts  (REQ  or  ANA,  HLD,  IMP)  but  the  traceability  is  only  one-way,  upward. 
The  traceability  is  recorded  in  one  of  several  documents — Software  Requirements  Specification  (SRS),  Engineering 
Requirements  Specification  (ERS),  Software  Design  Specification  (SDS),  or  a  component  plan. _ 

There  are  no  templates  or  examples  provided  for  the  SRS,  ERS,  and  SDS,  and  only  an  implied  one  (the  PSP  2.1  or  3.0 
Plan  Summary)  for  a  component  plan. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 

Several  possible  implementations:  specify  in  the  Customer  Interface  Manager  role  specification;  specify  traceability  in 
both  directions  in  scripts  REQ,  ANA,  HLD,  IMP;  provide  a  traceability  matrix  template  or  a  tool  requirement  for  bi¬ 
directional  traceability;  provide  implementation  examples  or  other  implementation  guidance  for  traceability;  possibly 
others.  Note  that  these  are  not  necessarily  mutually  exclusive. 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time  X  Reduced  Risk  X 

Describe  the  likely  benefits  of  the  suggested  change. 

Improves  quality  of  Customer  Interface  role  execution  by  leaving  less  to  chance,  could  reduce  cycle  time  dramatically 
where  changing  requirements  eat  up  trace  time,  and  reduces  risk  of  missing  a  necessary  work  product  change  when 
requirements  change. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 


Name 

James  McHale  /  Gene  Miluk 

Date  7  July  2008 

e-mail 

idm(5)sei. cmu.edu  /  gem(q)sei. cmu.edu 

Organization 

SEI 

Project 

TSP-CMMI  AIM 

Launch/Phase 

Engineering  PAs 

PIP  Number 

ENGR-2 

Priority 

High 

Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 


Ref.  RD  SP  1.1,  SP  1.2,  SP  2.3;  TS  SP  2.3;  PI  SP  2.1,  SP  2.2  SP3.1,  SP  3.3— All  of  these  CMMI  specific  practices  deal 
with  interfaces  in  some  way. _ 

Direction  in  TSP  scripts  REQ,  HLD,  and  IMP  is  extremely  high-level  and  generally  has  no  other  documentation, 
examples,  or  templates  to  fall  back  on.  (Note:  There  is  fairly  explicit  direction  at  the  lowest  implementation  level  in  script 
IMP6.) _ 

Role  manager  specifications  do  not  call  out  interfaces  as  a  specific  concern  or  responsibility,  with  the  possible  exception 
of  the  Customer  Interface  Manager  (not  necessarily  the  kind  of  interface  referred  to  in  CMMI). 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 

Potential  modifications  to  the  role  specifications  for  the  Customer  Interface,  Design,  Implementation,  and  Test  Managers. 
Potential  modifications  to  scripts  REQ/ANA,  HLD,  and  IMP  (although  IMP  might  be  okay  since  IMP6  goes  into  relevant 
detail). _ 

Some  level  of  operational  guidance  is  advisable  in  the  implementation  guidelines  for  TSP-CMMI  AIM. 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time  X  Reduced  Risk  X 

Describe  the  likely  benefits  of  the  suggested  change. 

Quality  of  TSP  implementation  and  CMMI  conformance  should  improve,  as  well  as  the  quality  of  the  product,  if  product 
interfaces  are  properly  specified,  designed,  implemented,  and  tested. _ 

Attention  to  interfaces  early  on  during  TSP  implementation  should  reduce  CMMI  implementation  cycle  time  while 
reducing  technical  risk  both  for  development  projects  and  for  the  TSP-CMMI  implementation  project. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 

Name  James  McHale  /  Gene  Miluk _  Date  7  July  2008 

e-mail  jdm@sei.cmu.edu  /  gem@sei.cmu.edu _  Organization  SEI _ 

Project  TSP-CMM1  AIM _  Launch/Phase  Engineering  PAs _ 


PIP  Number  ENGR-3 _  Priority  High 


Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 

Ref.  all  15  SGs  and  45  SPs  in  the  Engineering  PAs  (REQM,  RD,  TS,  PI,  VER,  VAL) — TSP  scripts  that  directly  address 
these  CMMI  goals  and  practices  (DEV,  MAINT,  REQ,  ANA,  HLD,  IMP,  IMP6)  and  in  general  high-level  and  rarely 
implemented  closely  by  target  organizations.  (The  lone  exception  is  script  INS  that  is  often  implemented  and  satisfies  a 
significant  portion  of  the  VER  process  area.) _ 

See  also  PIPs  ENGR-1  and  ENGR-2  for  examples  of  major  groups  of  practices  that  are  not  well  addressed  for  SCAMPI 
purposes. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 

Scripts  DEV,  MAINT,  REQ,  ANA,  HLD,  IMP,  and  possibly  IMP6  or  their  functional  equivalent  must  be  developed, 
adapted,  or  otherwise  instantiated  at  both  the  organizational  and  team  levels.  One  possible  solution  is  a  new  operational 
guidance  document,  combined  with  relatively  minor  enhancements  to  the  existing  scripts  and  role  manager 
specifications,  that  provides  explicit  guidelines  for  involving  working  developers  in  defining,  documenting,  and  changing 
their  own  engineering  process  descriptions. 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time  X  Reduced  Risk  X 

Describe  the  likely  benefits  of  the  suggested  change. 

Improved  quality  of  TSP  implementation  and  of  CMMI  conformance. _ 

Reduced  time  to  implement  CMMI  by  focusing  on  ML3  issues  in  an  effective  way  early  in  the  improvement  cycle. _ 

Reduced  risk  in  CMMI  implementation  by  addressing  potential  problem  areas  early  and  involving  working  developers  in 
defining,  adapting,  and  documenting  workable  standard  engineering  processes. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 


Name 

James  McHale 

Date  3/6/2008 

e-mail 

idm@sei.cmu.edu 

Organization 

SEI 

Project 

TSP  AIM 

Launch/Phase 

Project  Mgmt — ML3 

PIP  Number 

IPM-1 

Priority 

High 

Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 


Ref.  IPM  SP  1.2 — Modify  LAU4  step  5  to  reference  relevant  organizational  historical  data  (if  available)  for  estimation 
purposes. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 


LAU4 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time _  Reduced  Risk  X 

Describe  the  likely  benefits  of  the  suggested  change. 

Improve  the  quality  of  planning  estimates,  reduce  the  risks  associated  with  possibly  ignoring  relevant  organizational  data, 
and  improve  CMMI  conformance. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 


Name 

James  McHale 

Date  3/6/2008 

e-mail 

idm@sei.cmu.edu 

Organization 

SEI 

Project 

TSP  AIM 

Launch/Phase 

Project  Mgmt — ML3 

PIP  Number 

IPM-2 

Priority 

High 

Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 


Ref.  IPM  SP  2.2 — Identify  critical  internal  and  external  dependencies  explicitly  in  LAU3  step  4  (strategy)  and  possibly 
somewhere  in  LAU4  or  LAU6. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 
LAU3,  possibly  LAU4  and  LAU6 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time _  Reduced  Risk  X _ 

Describe  the  likely  benefits  of  the  suggested  change. 

Improve  the  quality  of  the  project  plan  and  reduce  project  risk  by  having  a  consistent  place  to  deal  with  critical 
dependencies,  and  improve  CMMI  conformance. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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Name 

James  McHale  /  Gene  Miluk 

Date  14-Apr-08 

e-mail 

idm(5)sei. cmu.edu  /  gem(g)sei. cmu.edu 

Organization 

SEI 

Project 

TSP  AIM 

Launch/Phase 

Support  PAs — ML2 

PIP  Number 

MA-1 

Priority 

Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 


Ref.  SP1.1 — “Establish  and  maintain  measurement  objectives  that  are  derived  from  identified  information  needs  and 
objectives.” _ 

Ref.  SP1.2 — “Specify  measures  to  address  the  measurement  objectives.” _ 

While  the  measurement  objectives  of  the  TSP  are  well-known  and  discussed  extensively  in  the  literature,  there  is  no 
central  location  within  the  TSP  artifacts  where  the  objectives  are  made  explicit;  therefore  there  is  no  explicit  link  between 
the  standard  TSP  measures  and  those  objectives. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 

One  way  to  implement  might  be  the  Indicator  Template  (new  to  TSP,  although  examples  were  created  for  the  “Jump- 
Starting”  class)  as  taught  in  the  SEMA  class  “Implemented  Goal-Driven  Measurement”  (this  is  an  implementation  of  the 
GQ(I)M  paradigm.  One  nuance  of  this  is  that  there  can  be  one  set  for  ML2  implementations  (e.g.,  earned  value  charts  for 
a  single  project),  and  an  additional  set  for  ML3  implementations  (e.g.,  showing  CPI  and  SPI  for  multiple  projects).  Note: 
there  might  be  an  opportunity  here  to  specify  standard  ML4/ML5  indicators  for  TSP  that  fulfill  the  requirement  for  process 
performance  baselines. 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time _  Reduced  Risk  X 

Describe  the  likely  benefits  of  the  suggested  change. 

Improved  communications  between  the  TSP  team  and  management,  and  improved  CMMI  conformance. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 

Name  James  McHale  /  Gene  Miluk _  Date  1 -May-08 

e-mail  jdm@sei.cmu.edu  /  gem@sei.cmu.edu _  Organization  SEI _ 

Project  TSP-CMM1  AIM _  Launch/Phase  ML2 — Proc.  Mgmt  &  Supp 


PIP  Number  OPD-1 _  Priority  High 


Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 

Ref.  OPD  SGI — “A  set  of  organizational  process  assets  is  established  and  maintained.”  Included  in  this  should  be  a  set 
of  standard  processes  (SP1.1),  life-cycle  models  approved  for  use  in  the  organization  (SP1.2),  tailoring  criteria  (SP1.3),  a 
measurement  repository  (SP1.4),  a  process  asset  library  (SP1.5),  and  work  environment  standards  (SP1.6)  which 
includes  things  like  PC  specifications  (hardware  and  software),  facilities  requirements,  etc.  Most  of  this  already  exists  in 
some  form  in  the  standard  TSP  process  assets,  plus  some  specific  items  in  the  current  PSP  and  TSP  books  by  Watts 
Humphrey  or  in  the  TSP-MT  (multi-team)  process  extension.  A  few  additional  items  should  be  created,  e.g.,  see  OPD-2 
regarding  tailoring  criteria  and  OPD-3  regarding  a  measurement  repository.  A  baseline  Organization  Standard  Set  of 
Processes  (OSSP)  should  include  all  of  this  as  well  and  provide  guidance  for  local  additions  and  extensions,  and  be 
collected  under  an  Organizational  Process  Notebook. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 

An  annotated  listing  of  TSP  process  elements,  including  extensions  not  currently  part  of  the  TSP  baseline,  should  be 
created  as  a  guide  or  table  of  contents  as  to  what  is  available.  For  an  example,  see  Section  5  of  CMU/SEI-2004-TR-014 
Mapping  TSP  to  CMMI  (essentially  an  extended,  annotated  version  of  the  index  already  in  TSP)  [McHale  2004],  This  list 
could  be  updated  and  extended,  and  the  Organizational  Process  Notebook  then  built  around  this. 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time  X  Reduced  Risk  X 

Describe  the  likely  benefits  of  the  suggested  change. 

By  extending  and  documenting  the  “official”  TSP  process  assets  in  this  way,  all  aspects  of  CMMI  implementation  using 
TSP  as  the  central  implementation  mechanism  are  improved — the  quality  of  the  results,  reduced  cycle  time  in  achieving 
those  results,  and  reduced  risk  in  achieving  those  results. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 

Name  James  McHale  /  Gene  Miluk _  Date  1 -May-08 

e-mail  jdm@sei.cmu.edu  /  gem@sei.cmu.edu _  Organization  SEI _ 

Project  TSP-CMM1  AIM _  Launch/Phase  ML2 — Proc.  Mgmt  &  Supp 


PIP  Number  OPD-2 _  Priority  High 


Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 

Ref.  OPD  SP1.3 — “Establish  and  maintain  the  tailoring  criteria  and  guidelines  for  the  organization’s  set  of  standard 
processes.”  Minimal  guidelines  for  tailoring  launch  preparation  materials,  launch  scripts,  role  descriptions,  engineering 
process  scripts,  and  other  TSP  process  assets  should  be  created  for  review  and  use  by  a  TSP  team  during  launches  and 
relaunches.  The  most  likely  place  to  reference  the  tailoring  criteria  are  in  launch  preparation  materials,  the  process 
manager  role  description,  and  especially  in  LAU3  for  use  when  the  team  is  defining  its  work  processes. _ 

The  tailoring  guidelines  might  also  include  a  waiver  process,  including  the  ability  to  easily  try  a  brand  new  process. _ 

Tailoring  guidelines  should  ensure  that,  if  CMMI  conformance  is  important  in  the  organization,  the  tailored  process  is  still 
CMMI-conformant  (e.g.,  by  having  the  EPG  review  changes). 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 

LAU3  (step  6  most  likely),  Process  Manager  Role  Description,  Launch  Preparation  Packages  for  the  Team  Leader  and 
Team  Members.  It  may  make  sense  to  include  an  example  of  a  tailored  launch  script  (e.g.,  for  launching  an  EPG) 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time  X  Reduced  Risk  X 

Describe  the  likely  benefits  of  the  suggested  change. 

Creates  a  standard  organization  for  process  assets  that  should  enable  better  and  more  obvious  conformance  with  CMMI 
ML3  requirements,  much  faster  startup  for  CMMI  efforts,  and  therefore  reduce  the  risk  of  non-conformance  issues. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 

Name  James  McHale  /  Gene  Miluk _  Date  2-May-08 

e-mail  jdm@sei.cmu.edu  /  gem@sei.cmu.edu _  Organization  SEI _ 

Project  TSP-CMM1  AIM _  Launch/Phase  ML2 — Proc.  Mgmt  &  Supp 


PIP  Number  OPD-3 _  Priority  High 


Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 

Ref.  OPD  SP1.4 — “Establish  and  maintain  the  organization’s  measurement  repository.”  The  standard  PM  script  specifies 
what  analyses  to  perform  at  a  very  high  level,  but  has  no  detail  on  how  to  perform  the  analyses  or  what  format  the 
resulting  data  should  follow.  The  potential  therefore  is  that  each  project  will  do  it  differently,  making  summaries, 
comparisons,  and  other  analyses  at  the  organizational  level  difficult  or  impossible.  Therefore  TSP  should  specify  at  least 
a  default  format  for  analyses  and  results,  allowing  the  starting  definition  of  the  organization’s  measurement  repository  to 
be  the  collection  of  weekly  consolidated  workbooks  plus  the  PM  results. _ 

Note:  There  is  strong  interaction  also  with  GP3.2  “Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing  the  <X>  process  to  support  the  future  use  and 
improvement  of  the  organization’s  processes  and  process  assets.”  While  weekly  consolidations  from  all  projects  are  a 
good  foundation,  having  the  PM  results  much  more  strongly  and  obviously  supports  the  purpose  of  GP3.2,  supporting 
future  use  and  improvement. _ 

Note:  There  is  also  obvious  interaction  with  PIP  MA-1  and  all  of  the  practices  in  Measurement  and  Analysis,  and 
possibly  with  TSP  Certification  efforts. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 

Script  PM  modifications,  possibly  to  the  extent  of  providing  an  example  minimum  output,  or  even  providing  a  default 
standard  format  for  results  that  lends  itself  to  cross-project  comparison  and  analysis. 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time  X  Reduced  Risk  X 

Describe  the  likely  benefits  of  the  suggested  change. 

Much  improved  uniformity  of  PM  results  making  both  target  organization  and  SEI  analysis  better,  quicker,  and  less 
expensive.  Also  reduces  the  risk  of  problems  in  OPD  evaluations  during  a  SCAMPI. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 

Name  James  McHale  /  Gene  Miluk _  Date  1 -May-08 

e-mail  jdm@sei.cmu.edu  /  gem@sei.cmu.edu _  Organization  SEI _ 

Project  TSP-CMM1  AIM _  Launch/Phase  ML2 — Proc.  Mgmt  &  Supp 


PIP  Number  OPF-1 _  Priority  High 


Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 

Ref.  OPF  SG3  “The  organizational  process  assets  are  deployed  across  the  organization  and  process-related 
experiences  are  incorporated  into  the  organizational  process  assets.”  The  existing  TSP  Introduction  Strategy  from 
Winning  with  Software  App.  F  should  be  updated  (and  separately  published  as  an  SEI  technical  note  or  part  of  a 
technical  report?)  to  include  suggested  CMMI  training,  appropriate  classes  of  SCAMPI  appraisals  and  other  evaluations 
(e.g.,  TSP  Organizational  Certification)  [Humphrey  2011], _ 

Ref.  OPF  SP1.1  “Establish  and  maintain  the  description  of  the  process  needs  and  objectives  for  the  organization.”  There 
is  no  standard  way  to  document  and  update  the  organization’s  process  needs  and  objectives.  At  a  minimum,  examples 
of  good  process  objectives  should  be  provided  as  part  of  AIM. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 
TSP  Introduction  Strategy 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time  X  Reduced  Risk  X 

Describe  the  likely  benefits  of  the  suggested  change. 

Faster,  more  consistent  and  persistent  implementation  of  TSP  in  an  organization,  and  reduced  risk  of  poor  CMMI 
implementation  of  CMMI  practices  not  previously  covered  by  standard  TSP. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 

Name  James  McHale  /  Gene  Miluk _  Date  1 -May-08 

e-mail  jdm@sei.cmu.edu  /  gem@sei.cmu.edu _  Organization  SEI _ 

Project  TSP-CMM1  AIM _  Launch/Phase  ML2 — Proc.  Mgmt  &  Supp 


PIP  Number  OPF-2 _  Priority  High 


Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 

Ref.  OPFSG2 — “Process  actions  that  address  improvements  to  the  organization’s  processes  and  process  assets  are 
planned  and  implemented.”  Also  ref.  OPF/OPD/OT  GPs  2.2  (“Plan  the  process”),  2.3  (“Provide  resources”),  2.4  (“Assign 
responsibility”),  2.5  (“Train  people”),  2.6  (“Manage  configurations”),  2.7  (“Identify  and  involve  stakeholders”),  and  GP  2.8 
(“Monitor  and  control  the  process”),  and  probably  others. _ 

Provide  guidance  to  train,  launch,  and  manage  the  EPG  or  equivalent  as  a  TSP  team.  This  should  include  standard 
LAU1  guidance  to  present  the  organization’s  process  needs  and  objectives  (see  PIP  OPF-1)  using  TSP  as  the  backbone 
of  such  an  effort.  The  scope  of  the  effort  should  include  directly  addressing  OPF,  OPD,  and  OT  at  a  minimum,  possibly 
extending  to  QA  and/or  CM,  in  addition  to  the  ‘standard’  TSP  focus  on  development  teams  which  normally  would  provide 
full  CMMI  coverage  to  Project  Management  and  Engineering  PAs. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 

Scripts  POPS,  POPS7,  and  POPS9  provide  a  good  starting  point,  although  these  should  be  updated  and  possibly 
extended.  (For  instance,  CMMI  should  be  referenced  as  the  base  model,  not  CMM.)  Additional  launch  preparation 
materials  and  role  descriptions  for  the  organizational  process  manager  and  the  process  group  should  be  provided. 
Scripts  TOPS  and  TOPS4  might  also  be  included  as  guidance. 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time  X  Reduced  Risk  X 

Describe  the  likely  benefits  of  the  suggested  change. 

Rapid  and  persistent  implementation  of  TSP,  and  reduced  risk  of  poor  choices  for  CMMI  implementation. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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Name  James  McHale  /  Gene  Miluk _  Date  2-May-08 

e-mail  jdm@sei.cmu.edu  /  gem@sei.cmu.edu _  Organization  SEI _ 

Project  TSP-CMMI  AIM _  Launch/Phase  ML3 — Process  Mgmt.  PAs 


PIP  Number  OT-1 _  Priority  High 


Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 

Ref.  OT  SG  1 — “A  training  capability,  which  supports  the  organization’s  management  and  technical  roles,  is  established 
and  maintained”  and  SG2  “Training  necessary  for  individuals  to  perform  their  roles  effectively  is  provided.”  The  specific 
practices  collectively  provide  the  relevant  guidance.  As  a  default,  training  is  initially  provided  by  an  outside  agent  such  as 
the  SEI  per  the  TSP-CMMI  AIM  Introduction  Strategy  (see  OPF-1)  and  then,  per  that  Strategy,  transitioned  to  the 
organization’s  EPG,  if  only  as  an  agent  for  securing  outside  training  resources.  Thus  OT  concerns  become  an  ongoing 
part  of  the  EPG’s  responsibilities  as  it  operates  as  a  TSP  team. _ 

Note:  Ref.  OT  SP1.2 — “Determine  which  training  needs  are  the  responsibility  of  the  organization  and  which  will  be  left  to 
the  individual  project  or  support  group.”  This  practice  in  particular  may  be  a  good  candidate  for  a  DAR  instantiation  (e.g., 
document  criteria  and  evaluation  methods  for  making  this  determination,  and  then  recording  results  accordingly  as  such 
decisions  are  made  on  an  ongoing  basis). 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 

TSP-CMMI  AIM  Introduction  Strategy,  specifically  those  parts  dealing  with  planning,  delivering,  and  evaluating  training  in 
PSP,  TSP,  and  CMMI  (by  default)  and  expanding  to  cover  all  organizational  training  needs.  Implementation  of  this  PIP 
must  address  all  relevant  artifacts  expected  by  the  SPs. 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time  X  Reduced  Risk  X 

Describe  the  likely  benefits  of  the  suggested  change. 

Elevates  the  training  needs,  capabilities,  and  outcomes  of  the  organization  early  in  the  Introduction  Strategy,  which 
should  help  to  ensure  a  quicker  buildup  in  internal  capability  and  more  of  a  quality  focus  earlier.  Should  also  somewhat 
reduce  the  risk  of  poor  CMMI  implementation  choices  being  made. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 


Name 

James  McHale 

Date 

3/6/2008 

e-mail 

idm@sei.cmu.edu 

Organization 

SEI 

Project 

TSP  AIM 

Launch/Phase 

Project  Mgmt. 

— ML2 

PIP  Number 

PMC-1 

Priority 

Low 

Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 


Ref.  PMC  GP  2.2 — Add  an  explicit  line  or  bullet  item  in  LAU8  or  LAUPM  for  the  team  leader  and  team  to  establish  a  set 
time  or  schedule  for  weekly  meetings. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 


LAU8  or  LAUPM 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time _  Reduced  Risk _ 

Describe  the  likely  benefits  of  the  suggested  change. 

Improves  the  fidelity  and  uniformity  of  TSP  implementation  by  ensuring  that  the  weekly  meetings  are  scheduled  during 
the  launch.  Currently  this  is  left  to  the  coach  to  check  with  the  team  sometime  during  the  launch  or  afterward  to  ensure 
that  this  happens. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 


Name 

James  McHale 

Date 

3/6/2008 

e-mail 

idm@sei.cmu.edu 

Organization 

SEI 

Project 

TSP  AIM 

Launch/Phase 

Project  Mgmt. 

— ML2 

PIP  Number 

PP-1 

Priority 

High 

Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 


Ref.  PP  SP2.3 — SP  says  “Plan  for  the  management  of  project  data”  which  is  done  on  every  project  but  has  no  specific 
guidance  in  the  TSP  to  plan  for  it.  The  project  NOTEBOOK  in  TSP  is  supposed  to  contain  this  data.  Suggest  adding 
guidance  in  PREPL/PREPR  to  set  up  the  NOTEBOOK. _ 

Ref.  PMC  SP1 .4 — SP  says  “Monitor  the  management  of  project  data  against  the  project  plan.”  Probably  a  good  specific 
checklist  item  for  the  process  manager  role. _ 

See  also  PIP  CM-1. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 
PREPL/PREPR  checklist,  Process  Manager  role  description. 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time _  Reduced  Risk  X 

Describe  the  likely  benefits  of  the  suggested  change. 

More  consistent  setup  and  maintenance  of  the  project  NOTEBOOK,  and  improved  CMMI  compliance. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 


Name 

Noopur  Davis  /  James  McHale 

Date 

11/14/16 

e-mail 

nd(a)sei. cmu.edu  /  idm(a)sei. cmu.edu 

Organization 

SEI 

Project 

TSP  Initiative 

Launch/Phase 

Project  Mgmt. 

— ML2 

PIP  Number 

PP-2 

Priority 

High 

Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 


Ref.  PP  SP2.5,  all  GP  2.5s  esp.  in  Engineering  PAs — SP  says  “Plan  for  knowledge  and  skills  needed  to  perform  the 
project.”  Somewhere  in  LAU3,  the  team  should  plan  for  training  needs  for  at  least  the  near-term  plan.  “Conventional” 
coaching  guidance  says  to  identify  training  needs  as  part  of  the  support  plan  (step  8)  thereby  recording  them  on  INV  and 
planning  in  LAU4,  but  LAU3  does  not  actually  say  this. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 


Script  LAU3 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time _  Reduced  Risk _ X 

Describe  the  likely  benefits  of  the  suggested  change. 


Explicitly  planning  for  training  will  improve  the  quality  of  the  end-product  by  improving  the  quality  of  process  execution, 
and  improve  CMMI  conformance. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 


Name 

James  McHale 

Date  3/6/08 

e-mail 

idm@sei.cmu.edu 

Organization 

SEI 

Project 

TSP  AIM 

Launch/Phase 

Project  Mgmt — ML2 

PIP  Number 

PP-3 

Priority 

High 

Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 


Ref.  PP  SP2.6 — “Plan  the  involvement  of  identified  stakeholders.”  Add  an  item  in  the  PREPL/PREPR  checklist  to 
develop  a  stakeholder  involvement  matrix.  The  purpose  of  this  matrix  would  be  to  try  to  identify  all  the  stakeholders 
before  the  launch,  and  invite  the  appropriate  ones  to  meetings  1  and  9.  This  matrix  could  also  be  used  later  (LAU3, 
LAU8,  and/or  WEEK)  to  determine  who  needs  what  status  from  the  project. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 
PREPL  &  PREPR  checklists,  possibly  Launch  Preparation  Guidelines,  possibly  LAU3,  LAU8,  and/or  WEEK 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time _  Reduced  Risk  X 

Describe  the  likely  benefits  of  the  suggested  change. 

Better  outcomes  for  launch  meetings  1  and  especially  9,  better  communication  with  other  relevant  stakeholders,  and 
reduced  risk  of  omitting  a  relevant  stakeholder;  also  improved  CMMI  conformance. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 


Name 

Tim  Chick 

Date 

5/20/2008 

e-mail 

tchick(a)sei. cmu.edu 

Organization 

TSP 

Project 

Launch/Phase 

PIP  Number 

Process  Review 

Priority 

Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 


All  references  to  the  “Process  Review  Meeting”  should  be  removed  from  the  TSP  material  as  it  is  undefined 
and  some  of  the  envisioned  material  is  already  covered  in  other  PSP/TSP  courses. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 
Not  a  complete  list,  but  PREPL  and  PREPR  to  start. 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time _  Reduced  Risk 

Describe  the  likely  benefits  of  the  suggested  change. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 


Name 

James  McHale 

Date  3/6/08 

e-mail 

idm@sei.cmu.edu 

Organization 

SEI 

Project 

TSP  AIM 

Launch/Phase 

Project  Mgmt — ML2 

PIP  Number 

QA-1 

Priority 

High 

Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 


Ref.  PP  GP2.9  (and  other  GP2.9s) — A  separate  TSP  QA  plan  could  address  many  QA  issues  between  TSP  and  CMMI. 
Currently  there  is  no  standard  guidance. 

See  also  PIP  ALL-2. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 

TSP  QA  Plan  (new),  possibly  including  a  TSP  Coach  role  description  that  emphasizes  preparation  and  training  as  well  as 
quality  assurance,  esp.  process  quality  assurance,  responsibilities. 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time _  Reduced  Risk  X _ 

Describe  the  likely  benefits  of  the  suggested  change. 

Provide  standard  QA  guidance  to  the  team  leader,  the  team,  the  organization,  and  the  coach,  while  improving  CMMI 
conformance. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 


Name 

James  McHale  /  Gene  Miluk 

Date  14-Apr-08 

e-mail 

idm(5)sei. cmu.edu  /  qem@sei.cmu.edu 

Organization 

SEI 

Project 

TSP  AIM 

Launch/Phase 

Engineering  PAs — ML2 

PIP  Number 

REQM-1 

Priority 

Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 


Ref.  SP1.1 — “Develop  an  understanding  with  the  requirements  providers  on  the  meaning  of  the  requirements.”  Scripts 
REQ  and  ANA  point  to  market  study  results,  impact  analyses,  ERS  (Engineering  Requirements  Specification),  and  SRS 
(System  Requirements  Specification)  but  there  is  no  specification  for  any  of  these  within  TSP.  Also,  while  one  may 
assume  that  SUMS  should  reflect  an  understanding  of  the  meaning  of  requirements  (presumably  through  the  conceptual 
design),  there  is  no  explicit  requirement  in  TSP  for  this. _ 

Ref.  SP1.4 — “Maintain  bi-directional  traceability  among  the  requirements  and  work  products.”  A  good  SUMS  will  have  a 
traceable  thread  to  tasks  in  individual  TASK  plans,  and  vice  versa.  However,  there  is  no  explicit  requirement  or  direction 
in  the  TSP  for  making  this  so. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 

New  process  elements  needed,  or  appropriate  places  found  for  the  following: _ 

1 .  Create  some  sort  of  minimal  specification  for  documents  that  reflect  an  explicit  understanding  of  requirements  (e.g., 

through  market  studies,  impact  analyses,  an  ERS,  and/or  an  SRS).  Note:  any  implementation  should  allow  for 
“requirements”  to  be  interpreted  fairly  broadly,  e.g.,  “requirements”  could  be  “contractual  requirements”  or  it  could  be 
“everything  we  understand  that  the  customer  wants." _ 

2.  Consider  specifying  some  sort  of  numbering  scheme  that  a.)  specifies  the  decomposition  of  requirements  through 
multiple  levels,  e.g.,  through  a  numbering  scheme  (like  the  part  number  on  SUMS)  that  might  be  implemented  via 
automation;  b.)  links  requirements  to  requirements/specification  documents  to  design  documents  to  code.  Some  of  this 
might  be  embedded  in  the  solution  to  #1.  Note:  “bi-directional  traceability”  should  be  broadly  defined  to  include  use 
cases,  architectural  descriptions,  detailed  designs,  code,  tests,  internal  and  user  documentation,  etc.  The  question  to  be 
answered  is  “Is  everything  required  reflected  in  the  code  (and  intermediate  products),  and  is  everything  in  the  code 
implementing  something  that  is  truly  required?” 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time _  Reduced  Risk  X 

Describe  the  likely  benefits  of  the  suggested  change. 

Should  improve  requirements  quality  on  a  TSP  team,  as  well  as  enhancing  requirements  traceability,  while  improving 
CMMI  implementation. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 


Name 

James  McHale 

Date  3/5/2008 

e-mail 

idm@sei.cmu.edu 

Organization 

SEI 

Project 

TSP  AIM 

Launch/Phase 

Project  Mgmt — ML3 

PIP  Number 

RSKM-1 

Priority 

High 

Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 


Ref.  RSKM  SP1.1 — Add  recommendation  in  LAU7  and  possibly  the  Launch  Preparation  Guidelines  to  reference 
CMU/SEI-93-TR-6  “Taxonomy-Based  Risk  Identification”  in  order  to  a.)  support  richer  brainstorming  of  risks  and  b.) 
comply  with  referenced  SP  which  reads  “Determine  risk  sources  and  categories.”  See  especially  p.  A-2  of  TR,  Figure  A- 
1  Taxonomy  of  Software  Development  Risks. 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 
LAU7,  possibly  the  Launch  Preparation  Guidelines  for  the  Team  Leader  and  Team  Members 


Improvement  Benefits  (check  one) 

Improved  Quality _  Reduced  Cycle  Time _  Reduced  Risk  X 

Describe  the  likely  benefits  of  the  suggested  change. 

Should  make  execution  of  LAU7  more  consistent  and  comprehensive  while  improving  CMMI  conformance. 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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TSP  Process  Improvement  Proposal — Form  PIP 


Name 

James  McHale 

Date  3/6/2008 

e-mail 

jdm@sei.cmu.edu 

Organization 

SEI 

Project 

TSP  AIM 

Launch/Phase 

Project  Mgmt. — ML2/3 

PIP  Number 

ROLE-1 

Priority 

High 

Improvement  Description 

Briefly  describe  the  improvement  you  suggest. 


Many  SPs  and  GPs  in  CMMI  are  performed  by  TSP  roles.  However  guidance  is  thin  for  planning  these  (one  line  in  LAU3) 
and  the  role  manager  descriptions  often  trigger  long  discussions.  Many  coaches  already  have  their  own  ‘private’  cache  of 
role  manager  guidance  (e.g.,  scripts  and/or  checklists).  This  guidance  should  be  standardized  (e.g.,  a  checklist  for  every 
team  role,  that  would  match  up  with  TASK  list  items  and  the  planned  time  to  execute  the  role  responsibilities). 


Process  Elements  Impacted 

If  you  know  them,  list  the  process  elements  that  must  be  added,  changed,  or  deleted 
T earn  role  descriptions,  including  especially  the  addition  of  a  sample  checklist  for  each  standard  role 


Improvement  Benefits  (check  one) 

Improved  Quality  X  Reduced  Cycle  Time _  Reduced  Risk _ 

Describe  the  likely  benefits  of  the  suggested  change. 

More  consistent  planning  and  performance  of  TSP  roles,  shortened  discussions  in  and  after  the  launch,  and  improved 
CMMI  conformance  for  many  SPs/GPs  (e.g.,  PP  SP2.3,  PMC  SP1 .4,  GP2.2,  GP2.3,  GP2.4,  GP2.6,  GP2.8,  GP2.9) 


When  completed  and  reviewed,  submit  to  the  Process  Manager  and  keep  a  copy. 
Do  not  write  below  this  line. 


PIP  Control# 
Received 
Evaluated 
Effort  involved 
Author  notified 
Reasons 


Accepted 
Returned 
Deferred 
Date  done 
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